[U-Boot] [PATCH] Don't inline weak symbols

Tom Tom.Rix at windriver.com
Tue Nov 3 15:04:40 CET 2009


Wolfgang Denk wrote:
> Dear Roman Zeyde,
> 
> In message <6d23e4ef0911030355j47a653a0iea7b6cae2f3cb180 at mail.gmail.com> you wrote:
>> I have noticed that the same error as described here
>> (http://lists.denx.de/pipermail/u-boot/2009-October/061913.html)
>> happens when compiling the latest version of U-boot (v2009-11-rc1)
>> using arm-cortex_a8-linux-gnueabi gcc version 4.4.0
>> (crosstool-NG-hg_default at 1620_187e06178dcb).
> 
> This has been discussed here before. Please see the archives.
> 
>> Could you please apply the patch described above to resolve this issue?
> 
> No, I will not. This has to go through the ARM custodian first.
> 
> Best regards,
> 
> Wolfgang Denk
> 

I am currently reviewing this patch.

After reviewing the history.
There is a interest in #if-defing this code.

The reason I can see is at least 2 of the start.S call

	bl	coloured_LED_init
	bl	red_LED_on

In general, what happens is they call into the weak
stubs.  Only if the cpu/board provides an overriding
function does these calls cause anything meaningful to
happen.

A good candidate for an if-def variable is the existing
CONFIG_STATUS_LED.

I am testing this change now.
Since it effects all the boards, I am using the regressions
of undefined symbol from MAKEALL arm to verify.

When this change is done there will only be a handful of
failures for the inline weak problem.

Then this patch to remove the inlines will take care of them.

I have looked at the assembly these produce and it does not
look different for non-inline to inline.  There was a slight
increase in the binary size (zoom2) of 8 bytes using
the code sourcry 2009.  For my roll-your-own gcc 4.4.2, the
size was about 400 bytes larger.  Of course it is harder to
tell since it wouldn't compile without the fix.

After I run through some more testing, I will send out
the patch set.

Tom


More information about the U-Boot mailing list