[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