[U-Boot] U-Boot Bug with newer GCC

[Priebe, Sebastian]

Hello,

> So it seems to be, that patch at least solves this issue.
> Sebastian: can you check if this is resolved also resolved for your board after applying http://patchwork.ozlabs.org/patch/217695/

Apperently we are still working with v2012.10. Could someone be so kind and provide a patch for v2012.10?
We plan to upgrade to v2013.01, but not before the end of Februay.

> Then this smells like a tool chain issue.  You might contact Pengutronix support for help with their tool chain.

We already asked Pengutronix.
They use barebox with their toolchains and didn't have any problem with their new toolchain, yet.
In their barebox.lds they have:
 __barebox_cmd_start = .;
 __barebox_cmd : { KEEP(*(SORT_BY_NAME(.barebox_cmd*))) }
 __barebox_cmd_end = .;

And they thought
         __u_boot_cmd_start = .;
        .u_boot_cmd : { KEEP(*(.u_boot_cmd)) }
        __u_boot_cmd_end = .;

would solve the problem. But it didn't.

Best regards.
Sebastian




==========================================
CADCON
Ingenieurgesellschaft mbH & Co. KG
Geschaeftsfuehrer: Robert Bauer, Andreas Gundel
Sitz der Gesellschaft: D-86368 Gersthofen
Registergericht: Amtsgericht Augsburg HRA 14521
==========================================
-----Ursprüngliche Nachricht-----
Von: Jeroen Hofstee [mailto:jeroen at myspectrum.nl]
Gesendet: Samstag, 2. Februar 2013 22:45
An: Wolfgang Denk
Cc: Jeroen Hofstee; Marek Vasut; Heiko Schocher; Priebe, Sebastian; u-boot at lists.denx.de
Betreff: Re: [U-Boot] U-Boot Bug with newer GCC

On 02/02/2013 10:22 PM, Wolfgang Denk wrote:
> Dear Jeroen Hofstee,
>
> In message <510D1D1E.7080705 at myspectrum.nl> you wrote:
>> yes, it is confusing. The following patch will e.g. make the trap go
>> away on the twister. Yet there is nothing wrong with the original
>> code it touches (or I fail to see what it is).
> Note that your patch breaks commands that use length modifiers ...
>
> Best regards,
>
> Wolfgang Denk
>
I'm aware of that. This is not a patch to be applied, just to illustrate the weirdness encountered (it explicitly says the code is fine before this). This is resolved for now, see

http://patchwork.ozlabs.org/patch/217695/

Regards,
Jeroen