[U-Boot] Missing __udivdi3 for ARM
I enabled CONFIG_YAFFS2 for ARM, and got the following message: /home/user/u-boot/fs/yaffs2/yaffscfg.c:185: undefined reference to `__udivdi3'
I know some other math routines have been fixed, is there a patch for this one? A few minutes of searching found some things from 2007-July, but it seemed to be refactoring the code rather than adding the function.
Thanks, --jc
Dear "J.C. Wren",
In message 17434f2e0907311440v2909bf46w74877af175f493e6@mail.gmail.com you wrote:
I enabled CONFIG_YAFFS2 for ARM, and got the following message: /home/user/u-boot/fs/yaffs2/yaffscfg.c:185: undefined reference to `__udivdi3'
I know some other math routines have been fixed, is there a patch for this one? A few minutes of searching found some things from 2007-July, but it seemed to be refactoring the code rather than adding the function.
I think Jean-Christophe has a patch to fix this, and I'm waiting all the time for him to post it.
Best regards,
Wolfgang Denk
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090801132619.GA19785@game.jcrosoft.org you wrote:
On 17:40 Fri 31 Jul , J.C. Wren wrote:
I enabled CONFIG_YAFFS2 for ARM, and got the following message: /home/user/u-boot/fs/yaffs2/yaffscfg.c:185: undefined reference to `__udivdi3'
just use lldiv
The big question here is if such a change makes sense; please keep in mind that the yaffs2 code is just borrowed from Linux, so changes should be kept to a minimum.
Actually I think it is only reasonable to assume that libgcc.a should include such a function.
Best regards,
Wolfgang Denk
On 16:40 Sat 01 Aug , Wolfgang Denk wrote:
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090801132619.GA19785@game.jcrosoft.org you wrote:
On 17:40 Fri 31 Jul , J.C. Wren wrote:
I enabled CONFIG_YAFFS2 for ARM, and got the following message: /home/user/u-boot/fs/yaffs2/yaffscfg.c:185: undefined reference to `__udivdi3'
just use lldiv
The big question here is if such a change makes sense; please keep in mind that the yaffs2 code is just borrowed from Linux, so changes should be kept to a minimum.
yaffs2 is not linux mainline and will never been as it's author do not care about it
I've already seen such problem wiht out of tree code
Best Regards, J.
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090801161409.GD19785@game.jcrosoft.org you wrote:
I enabled CONFIG_YAFFS2 for ARM, and got the following message: /home/user/u-boot/fs/yaffs2/yaffscfg.c:185: undefined reference to `__udivdi3'
just use lldiv
The big question here is if such a change makes sense; please keep in mind that the yaffs2 code is just borrowed from Linux, so changes should be kept to a minimum.
yaffs2 is not linux mainline and will never been as it's author do not care about it
Maybe. But that doesn't change the situation: the part of code you suggest to change gives no reasons for changes other that U-Boot's libgcc support is incomplete. So rather than fixing the symptoms, I prefer fixing the cause.
I've already seen such problem wiht out of tree code
Me too. But that doesn't mean we should add new problems, for example when we want to update the yaffs2 code in the future.
Best regards,
Wolfgang Denk
I thought the idea was to move u-boot away from libgcc dependencies. Or did I misread that? I know that a previous problem I commented on was solved by adding a __xxxxx.S function the u-boot library. --jc
On Sat, Aug 1, 2009 at 10:40 AM, Wolfgang Denk wd@denx.de wrote:
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090801132619.GA19785@game.jcrosoft.org you wrote:
On 17:40 Fri 31 Jul , J.C. Wren wrote:
I enabled CONFIG_YAFFS2 for ARM, and got the following message: /home/user/u-boot/fs/yaffs2/yaffscfg.c:185: undefined reference to `__udivdi3'
just use lldiv
The big question here is if such a change makes sense; please keep in mind that the yaffs2 code is just borrowed from Linux, so changes should be kept to a minimum.
Actually I think it is only reasonable to assume that libgcc.a should include such a function.
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de There is a multi-legged creature crawling on your shoulder. -- Spock, "A Taste of Armageddon", stardate 3193.9
Dear "J.C. Wren",
In message 17434f2e0908011243y666d2d40if6fdfd8a5c00c7c5@mail.gmail.com you wrote:
I thought the idea was to move u-boot away from libgcc dependencies. Or did I misread that? I know that a previous problem I commented on was solved by adding a __xxxxx.S function the u-boot library.
In a perfect world the GCC provided libgcc.a would be "just working" and we did not have to bother about all that.
But libgcc.a fo ARM is obviously not perfect, and causes problems. So Jean-Christophe suggested to use the alternative implementation he wanted to copy from the Linux code - which again is supposed to allow to use the code in question without changes.
But for some reason Jean-Christophe does not post a patch to add this Linux based new library code, but rather suggests to change the code instead - which I do not understand, and which I tend to disagree with.
Best regards,
Wolfgang Denk
Dear Wolfgang,
Wolfgang Denk wrote:
Dear "J.C. Wren",
In message 17434f2e0908011243y666d2d40if6fdfd8a5c00c7c5@mail.gmail.com you wrote:
I thought the idea was to move u-boot away from libgcc dependencies. Or did I misread that? I know that a previous problem I commented on was solved by adding a __xxxxx.S function the u-boot library.
In a perfect world the GCC provided libgcc.a would be "just working" and we did not have to bother about all that.
But libgcc.a fo ARM is obviously not perfect, and causes problems. So Jean-Christophe suggested to use the alternative implementation he wanted to copy from the Linux code - which again is supposed to allow to use the code in question without changes.
Just to get an idea what has to be done for this:
Do we talk about
http://lists.denx.de/pipermail/u-boot/2009-June/054627.html
without the changes to top level
Makefile arm_config.mk
?
That is, updating that patch and removing the Makefile and arm_config.mk changes would be what we want?
Best regards
Dirk
Dear Dirk Behme,
In message 4A753DB9.6080508@googlemail.com you wrote:
But libgcc.a fo ARM is obviously not perfect, and causes problems. So Jean-Christophe suggested to use the alternative implementation he wanted to copy from the Linux code - which again is supposed to allow to use the code in question without changes.
Just to get an idea what has to be done for this:
Do we talk about
http://lists.denx.de/pipermail/u-boot/2009-June/054627.html
without the changes to top level
Makefile arm_config.mk
Right. The patch needs to be updated so that the new runtime library functions replace the existing ones and get linked into lib_arm/libgcc.a instead.
That is, updating that patch and removing the Makefile and arm_config.mk changes would be what we want?
That's what Jean-Christphe proposed - I am not in a position to judge if this really solves all the problems we have on ARM. Looking at the code I see things like:
+ * linux/arch/arm/lib/lib1funcs.S: Optimized ARM division routines + * + * Author: Nicolas Pitre <nico at cam.org> + * - contributed to gcc-3.4 on Sep 30, 2003 + * - adapted for the Linux kernel on Oct 2, 2003
That reads as if this was 6 years old code, which looks as if it was two years older than what we currently have in U-Boot.
I wonder if it would not make more sense to copy the C code from some recent GCC version instead - it may be a few percent less efficient in terms of size and performance, but looking where such reoutines are actually used in U-Boot I thinl probably nobody would ever notice the difference.
So probably someone with a deeper understanding of GCC support for ARM is required to make a qualified assessment, and in any case thorogh testing needs to be done.
Best regards,
Wolfgang Denk
participants (4)
-
Dirk Behme -
J.C. Wren -
Jean-Christophe PLAGNIOL-VILLARD -
Wolfgang Denk