Re: Default build-many-glibcs.py to GCC 7 branch [committed]

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 10 May 2017, Zack Weinberg wrote:

> On Wed, Apr 26, 2017 at 11:28 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> > Now there is a GCC 7 release branch, this patch makes
> > build-many-glibcs.py default to using it instead of GCC 6.
> >
> > Relative to GCC 6, this fixes the MicroBlaze build but introduces ICEs
> > building glibc testcases for SH (GCC PRs 78459, 78460; the latter is
> > an out-of-memory issue so you may want to set memory limits when
> > running build-many-glibcs.py).
> 
> This does not seem to have fixed MicroBlaze; the glibc build within
> the compilers step bombs out with
> 
> /home/zack/projects/glibc-many/install/compilers/microblaze-linux-gnu/lib/gcc/microblaze-glibc-linux-gnu/7.1.1/../../../../microblaze-glibc-linux-gnu/bin/ld:
> /home/zack/projects/glibc-many/build/compilers/microblaze-linux-gnu/glibc/microblaze-linux-gnu/nptl/libpthread.so:
> invalid string offset 4168712877 >= 4898 for section `.dynstr'
> /home/zack/projects/glibc-many/build/compilers/microblaze-linux-gnu/glibc/microblaze-linux-gnu/nptl/libpthread.so:
> error adding symbols: File format not recognized
> collect2: error: ld returned 1 exit status
> ../Makerules:582: recipe for target
> '/home/zack/projects/glibc-many/build/compilers/microblaze-linux-gnu/glibc/microblaze-linux-gnu/rt/librt.so'
> failed
> 
> If I remember correctly, this is the same syndrome observed with gcc 6.

For whatever reason, I don't see this with my bot.

https://sourceware.org/ml/libc-testresults/2017-q2/msg00137.html
https://sourceware.org/ml/libc-testresults/2017-q2/msg00152.html

(The "FAIL: glibcs-microblaze-linux-gnu check" is just elf/check-execstack 
failing.)

The problem observed with GCC 6 was lack of DWARF EH support, meaning the 
first glibc built OK with SJLJ EH, but then the second glibc build, built 
with a compiler using shared libgcc, fell over with undefined symbol 
references (the "compilers" stage succeeded, the "glibcs" stage failed).

That said, 
<https://lists.yoctoproject.org/pipermail/meta-xilinx/2016-November/002258.html> 
seems to have a plausible explanation of the problem (alias to undefined 
__libc_vfork, apparently triggering a linker bug).  I'd prefer making 
MicroBlaze follow the same symbol handling as other architectures (so 
defining __libc_vfork and then defining other symbols as aliases to it) 
over the approach in that patch of a MicroBlaze-specific pt-vfork.S.

-- 
Joseph S. Myers
joseph@codesourcery.com