[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