[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
Dirk Behme
dirk.behme at googlemail.com
Sun Jul 12 16:55:22 CEST 2009
Dear Wolfgang,
Wolfgang Denk wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
>
> In message <20090712120655.GA21713 at game.jcrosoft.org> you wrote:
>>> It will hush up the current errors, but that's actually a bad thing
>>> here - the errors are an indication that Jean-Christophe's patch
>>> might not be working as it is supposed to.
>> They do fix what they are suppose to , fix FPU and EABI problem which was
>> re-introduce by the 64 bit mtd support
>> here the problem is different you try to div64 which is not supported on arm
>> you do need to do_div
>
> What do you mean - not supported by ARM? Of course ARM supports 64
> bit division.
>
> Compiling this little test code:
>
> long long div(long long x, long long y)
> {
> return x / y;
> }
>
> will result in a call to __aeabi_ldivmod using an EABI compliant
> version of GCC, resp. to __divdi3 using an older compiler. So GCC
> knows how to handle this, and it provides adequate functions to do
> it.
>
>> please apply this patch so I'll be able to send a pull request with the arm
>> specific part and other patch be go in vacancy for one week this night
>
> I really hesitate to do that. It seems that not using the compiler
> provided library is not such a clever thing to do. The compile writes
> probably know better what a specific version of GCC needs that
> anybody else.
Yes, you are basically right. But ;)
But, as Jean-Christophe mentioned above, it's a pain with the various
ARM tool chains floating around. Some are older, some are newer, some
are configured for EABI, some not, some are configured for software
floating point, some for hardware floating point, etc., etc.
While I as developer might be able to find a recent tool chain with a
libgcc compatible with U-Boot, I think we should avoid this pain for
our users. Users which like to "just compile U-Boot" and then we tell
them "well, your tool chain you seem to be happy with doesn't link
U-Boot, for U-Boot you have to install an other one" I think wouldn't
make them happy.
Regarding not using the compilers library and if this clever: No, it
isn't clever, you are right again. The compiler's library version is
most probably better optimized. But, we are dealing with a boot loader
here. So for the topic we discuss here, I think avoiding some pain for
us ("my tool chain doesn't compile U-Boot, help!" mails at this list)
and our users (see above) is the stronger argument than some
optimization/performance issues in some (seldom?) used math functions.
Best regards
Dirk
More information about the U-Boot
mailing list