Dear Joakim, dear Dirk,
In message OF14C3D470.864842B6-ONC1257D7A.002471AC-C1257D7A.0024DEC4@transmode.se you wrote:
Ouch, that was a nasty surprise.
Indeed.
In my original mail I referenced this potential solution, at least it worked for me: https://gcc.gnu.org/ml/gcc-help/2014-02/msg00054.html
That looks like the correct fix but I presume both .data.rel.ro and data.rel.ro.local should be added?
I can confirm:
1) The problem was observed with gcc 4.8.1 [as in Yocto 1.5.x / ELDK 5.5.x].
2) Switching back to gcc 4.7.2 [as in Yocto 1.4 / ELDK 5.4] makes the problem go away.
3) Switching forward to gcc 4.9.1 [as in Yocto 1.7 / ELDK 5.7] makes the problem go away.
4) For the problemativ 4.8.x versions of GCC, the following patch apparently solves the problem for my (MPC5200 based) board - guess this would have to be applied to all .lds files...
diff --git a/arch/powerpc/cpu/mpc5xxx/u-boot.lds b/arch/powerpc/cpu/mpc5xxx/u-boot.lds index cd9e23f..82c86d7 100644 --- a/arch/powerpc/cpu/mpc5xxx/u-boot.lds +++ b/arch/powerpc/cpu/mpc5xxx/u-boot.lds @@ -27,6 +27,8 @@ SECTIONS { _GOT2_TABLE_ = .; KEEP(*(.got2)) + KEEP(*(.data.rel.ro)) + KEEP(*(.data.rel.ro.local)) KEEP(*(.got)) PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4); _FIXUP_TABLE_ = .;
Given that GCC 4.9.1 apparently solves this issue I wonder which approach we should take?
Should we blacklist GCC 4.8.x (and 4.9.0) like the kernel folks are doing [1] ?
[1] https://lkml.org/lkml/2014/10/10/272
Best regards,
Wolfgang Denk