Are you sure it is not related on how you build your toolchain? I am asking because Joseph has a build service that constantly check glibc build against multiple architectures and we have not seen this issue [1].

I have rebuild toolchain for or1k and mips64el using gcc-10/gcc-11 along with binutils 2.39 and glibc-2.36 branches and I have seen only an ICE in the compiler when using --enable-profile with GCC (by removing the configure switch I could complete the build).

[1] https://sourceware.org/pipermail/libc-testresults/2022q3/009900.html

(In reply to Adhemerval Zanella from comment #1)
> Are you sure it is not related on how you build your toolchain? I am asking
> because Joseph has a build service that constantly check glibc build against
> multiple architectures and we have not seen this issue [1].

It's a possibility but it's unclear what could be causing this.

> 
> I have rebuild toolchain for or1k and mips64el using gcc-10/gcc-11 along
> with binutils 2.39 and glibc-2.36 branches and I have seen only an ICE in
> the compiler when using --enable-profile with GCC (by removing the configure
> switch I could complete the build).

I'm seeing these builds failing with errors when --disable-profile is passed:
http://autobuild.buildroot.net/results/883/883b171a856a63540908976592683527fdb21cd2/glibc-2.36-44-g2628500f5dff1dd99c49a09b418b3b1ea3a6b5d3/build/config.log
http://autobuild.buildroot.net/results/883/883b171a856a63540908976592683527fdb21cd2/build-end.log

Configured like this looks like(note that autobuilder host is aarch64 based, however I'm seeing similar errors on our x86_64 build hosts):
/home/autobuild/autobuild/instance-4/output-1/build/glibc-2.36-44-g2628500f5dff1dd99c49a09b418b3b1ea3a6b5d3/configure --target=mipsel-buildroot-linux-gnu --host=mipsel-buildroot-linux-gnu --build=aarch64-unknown-linux-gnu --prefix=/usr --enable-shared --with-pkgversion=Buildroot --disable-profile --disable-werror --without-gd --with-headers=/home/autobuild/autobuild/instance-4/output-1/host/mipsel-buildroot-linux-gnu/sysroot/usr/include --enable-kernel=5.16

Easiest way to reproduce buildroot autobuilder errors is like this(using config for above failure as an example):
git clone https://github.com/buildroot/buildroot.git
cd buildroot
wget http://autobuild.buildroot.net/results/883/883b171a856a63540908976592683527fdb21cd2/config
mv config .config
make glibc

To make the same build using your normal local glibc git tree for testing glibc changes:
Simply create a local.mk file inside the buildroot tree:
echo "GLIBC_OVERRIDE_SRCDIR = /home/buildroot/glibc" > local.mk

Then to rebuild/resync testing changes from your local glibc checkout:
make glibc-rebuild

Reference manual for local.mk overrides:
https://buildroot.org/downloads/manual/manual.html#_using_buildroot_during_development

> 
> [1] https://sourceware.org/pipermail/libc-testresults/2022q3/009900.html

Is there an easy way to reproduce it without resorting to build/use buildroot? I am trying to use the command you posted but it fails after downloading the kernel and I do not want to dig into builroot to debug this.

Also, could you verify what buildroot is doing differently than glibc own toolchain build script [1] so we can narrow down issue?

[1] https://sourceware.org/git/?p=glibc.git;a=blob;f=scripts/build-many-glibcs.py;h=5af6f369ae04027911b3407c64716dd1571eae6a;hb=HEAD

(In reply to Adhemerval Zanella from comment #3)
> Is there an easy way to reproduce it without resorting to build/use
> buildroot? I am trying to use the command you posted but it fails after
> downloading the kernel and I do not want to dig into builroot to debug this.
> 
> Also, could you verify what buildroot is doing differently than glibc own
> toolchain build script [1] so we can narrow down issue?
> 
> [1]
> https://sourceware.org/git/?p=glibc.git;a=blob;f=scripts/build-many-glibcs.
> py;h=5af6f369ae04027911b3407c64716dd1571eae6a;hb=HEAD

Hmm, what's the error message buildroot gives?

I'm not really sure how to reproduce outside of buildroot. Kind of hard to narrow down what difference is triggering the issue with the toolchain build script.

(In reply to James Hilliard from comment #4)
> (In reply to Adhemerval Zanella from comment #3)
> > Is there an easy way to reproduce it without resorting to build/use
> > buildroot? I am trying to use the command you posted but it fails after
> > downloading the kernel and I do not want to dig into builroot to debug this.
> > 
> > Also, could you verify what buildroot is doing differently than glibc own
> > toolchain build script [1] so we can narrow down issue?
> > 
> > [1]
> > https://sourceware.org/git/?p=glibc.git;a=blob;f=scripts/build-many-glibcs.
> > py;h=5af6f369ae04027911b3407c64716dd1571eae6a;hb=HEAD
> 
> Hmm, what's the error message buildroot gives?
> 
> I'm not really sure how to reproduce outside of buildroot. Kind of hard to
> narrow down what difference is triggering the issue with the toolchain build
> script.

I just copy/paste your instructions:

---
git clone https://github.com/buildroot/buildroot.git
cd buildroot
wget http://autobuild.buildroot.net/results/883/883b171a856a63540908976592683527fdb21cd2/config
mv config .config
make glibc
---

And after it build first stage of GCC, it tries to download the kernel and dumps an error:

---
wget --passive-ftp -nd -t 3 -O '/tmp/buildroot/buildroot/output/build/.linux-5.17.15.tar.xz.MfDZZc/output' 'https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.17.15.tar.xz'
--2022-10-26 16:09:00--  https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.17.15.tar.xz
Resolving cdn.kernel.org (cdn.kernel.org)... 2a04:4e42:5c::432, 199.232.113.176
Connecting to cdn.kernel.org (cdn.kernel.org)|2a04:4e42:5c::432|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 128442092 (122M) [application/x-xz]
Saving to: ‘/tmp/buildroot/buildroot/output/build/.linux-5.17.15.tar.xz.MfDZZc/output’

/tmp/buildroot/buildroot/output/build/.linux-5.17.15.tar.xz.MfDZZc/output      100%[====================================================================================================================================================================================================>] 122,49M  36,0MB/s    in 3,3s

2022-10-26 16:09:08 (37,4 MB/s) - ‘/tmp/buildroot/buildroot/output/build/.linux-5.17.15.tar.xz.MfDZZc/output’ saved [128442092/128442092]

ERROR: No hash found for linux-5.17.15.tar.xz
---

(In reply to Adhemerval Zanella from comment #5)
> (In reply to James Hilliard from comment #4)
> > (In reply to Adhemerval Zanella from comment #3)
> > > Is there an easy way to reproduce it without resorting to build/use
> > > buildroot? I am trying to use the command you posted but it fails after
> > > downloading the kernel and I do not want to dig into builroot to debug this.
> > > 
> > > Also, could you verify what buildroot is doing differently than glibc own
> > > toolchain build script [1] so we can narrow down issue?
> > > 
> > > [1]
> > > https://sourceware.org/git/?p=glibc.git;a=blob;f=scripts/build-many-glibcs.
> > > py;h=5af6f369ae04027911b3407c64716dd1571eae6a;hb=HEAD
> > 
> > Hmm, what's the error message buildroot gives?
> > 
> > I'm not really sure how to reproduce outside of buildroot. Kind of hard to
> > narrow down what difference is triggering the issue with the toolchain build
> > script.
> 
> I just copy/paste your instructions:
> 
> ---
> git clone https://github.com/buildroot/buildroot.git
> cd buildroot
> wget
> http://autobuild.buildroot.net/results/883/
> 883b171a856a63540908976592683527fdb21cd2/config
> mv config .config
> make glibc
> ---
> 
> And after it build first stage of GCC, it tries to download the kernel and
> dumps an error:
> 
> ---
> wget --passive-ftp -nd -t 3 -O
> '/tmp/buildroot/buildroot/output/build/.linux-5.17.15.tar.xz.MfDZZc/output'
> 'https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.17.15.tar.xz'
> --2022-10-26 16:09:00-- 
> https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.17.15.tar.xz
> Resolving cdn.kernel.org (cdn.kernel.org)... 2a04:4e42:5c::432,
> 199.232.113.176
> Connecting to cdn.kernel.org (cdn.kernel.org)|2a04:4e42:5c::432|:443...
> connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 128442092 (122M) [application/x-xz]
> Saving to:
> ‘/tmp/buildroot/buildroot/output/build/.linux-5.17.15.tar.xz.MfDZZc/output’
> 
> /tmp/buildroot/buildroot/output/build/.linux-5.17.15.tar.xz.MfDZZc/output   
> 100%[========================================================================
> =============================================================================
> ===============================================>] 122,49M  36,0MB/s    in
> 3,3s
> 
> 2022-10-26 16:09:08 (37,4 MB/s) -
> ‘/tmp/buildroot/buildroot/output/build/.linux-5.17.15.tar.xz.MfDZZc/output’
> saved [128442092/128442092]
> 
> ERROR: No hash found for linux-5.17.15.tar.xz
> ---

Oh, build config is out of sync with master(sometime changes in master break previous configs), should work if you checkout the same buildroot commit that the failure was triggered on:
git checkout e4ecf82f99f53e55d51e6f74ae5021473aa2bb1d

Full commands:
git clone https://github.com/buildroot/buildroot.git
cd buildroot
git checkout e4ecf82f99f53e55d51e6f74ae5021473aa2bb1d
wget http://autobuild.buildroot.net/results/883/883b171a856a63540908976592683527fdb21cd2/config
mv config .config
make glibc

(In reply to James Hilliard from comment #6)
> 
> Full commands:
> git clone https://github.com/buildroot/buildroot.git
> cd buildroot
> git checkout e4ecf82f99f53e55d51e6f74ae5021473aa2bb1d
> wget
> http://autobuild.buildroot.net/results/883/
> 883b171a856a63540908976592683527fdb21cd2/config
> mv config .config
> make glibc

Ok, with this one I can see the buildroot failure. It seems that it is misconfiguring the stage1 gcc, where the libgcc.a generated is relying on the libc for unwinding (thus why ld.so link is failing).

I mimic what build-many-glibcs.py [1] does (which is canonical way to build complete toolchain for glibc) and build a stage1 on buildroot system with:

---
./configure \
  --prefix=/tmp/buildroot/output/host \
  --build=x86_64-pc-linux-gnu \
  --host=x86_64-pc-linux-gnu \
  --target=mips64el-glibc-linux-gnu \
  --sysconfdir=/tmp/buildroot/output/host/etc \
  --localstatedir=/tmp/buildroot/output/host/var \
  --target=mipsel-buildroot-linux-gnu \
  --with-sysroot=/tmp/buildroot/output/host/mipsel-buildroot-linux-gnu/sysroot \
  --with-gmp=/tmp/buildroot/output/host \
  --with-mpc=/tmp/buildroot/output/host \
  --with-mpfr=/tmp/buildroot/output/host \
  --with-pkgversion="Buildroot 2022.08-383-ge4ecf82f99-dirty" \
  --with-bugurl=http://bugs.buildroot.net/ \
  --enable-initfini-array \
  --disable-libssp \
  --disable-shared \
  --disable-threads \
  --disable-libatomic \
  --disable-decimal-float \
  --disable-libffi \
  --disable-libgomp \
  --disable-libitm \
  --disable-libmpx \
  --disable-libquadmath \
  --disable-libsanitizer \
  --without-headers\
  --with-newlib \
  --enable-languages=c, \
  --with-arch=mips32r3 --with-abi=32 --with-nan=legacy --with-fp-32=xx
---

And with this stage1 gcc I could finish the glibc build. I am afraid you will need to sort this out on buildroot stage1 configuration flags used on gcc.

[1] https://sourceware.org/git/?p=glibc.git;a=blob;f=scripts/build-many-glibcs.py;h=5af6f369ae04027911b3407c64716dd1571eae6a;hb=HEAD

(In reply to Adhemerval Zanella from comment #7)
> (In reply to James Hilliard from comment #6)
> > 
> > Full commands:
> > git clone https://github.com/buildroot/buildroot.git
> > cd buildroot
> > git checkout e4ecf82f99f53e55d51e6f74ae5021473aa2bb1d
> > wget
> > http://autobuild.buildroot.net/results/883/
> > 883b171a856a63540908976592683527fdb21cd2/config
> > mv config .config
> > make glibc
> 
> Ok, with this one I can see the buildroot failure. It seems that it is
> misconfiguring the stage1 gcc, where the libgcc.a generated is relying on
> the libc for unwinding (thus why ld.so link is failing).
> 
> I mimic what build-many-glibcs.py [1] does (which is canonical way to build
> complete toolchain for glibc) and build a stage1 on buildroot system with:
> 
> ---
> ./configure \
>   --prefix=/tmp/buildroot/output/host \
>   --build=x86_64-pc-linux-gnu \
>   --host=x86_64-pc-linux-gnu \
>   --target=mips64el-glibc-linux-gnu \

This looks wrong, we aren't building for mips64el(which our autobuilders also indicate does not have this particular build failure).

>   --sysconfdir=/tmp/buildroot/output/host/etc \
>   --localstatedir=/tmp/buildroot/output/host/var \
>   --target=mipsel-buildroot-linux-gnu \

Setting target a second time?

>  
> --with-sysroot=/tmp/buildroot/output/host/mipsel-buildroot-linux-gnu/sysroot
> \
>   --with-gmp=/tmp/buildroot/output/host \
>   --with-mpc=/tmp/buildroot/output/host \
>   --with-mpfr=/tmp/buildroot/output/host \
>   --with-pkgversion="Buildroot 2022.08-383-ge4ecf82f99-dirty" \
>   --with-bugurl=http://bugs.buildroot.net/ \
>   --enable-initfini-array \
>   --disable-libssp \
>   --disable-shared \
>   --disable-threads \
>   --disable-libatomic \
>   --disable-decimal-float \
>   --disable-libffi \
>   --disable-libgomp \
>   --disable-libitm \
>   --disable-libmpx \
>   --disable-libquadmath \
>   --disable-libsanitizer \
>   --without-headers\
>   --with-newlib \
>   --enable-languages=c, \
>   --with-arch=mips32r3 --with-abi=32 --with-nan=legacy --with-fp-32=xx
> ---

I've attempted to make a build using this configuration but have not been able to get a working build.

> 
> And with this stage1 gcc I could finish the glibc build. I am afraid you
> will need to sort this out on buildroot stage1 configuration flags used on
> gcc.

I've tested by patching our gcc stage1 configure(package/gcc/gcc-initial/gcc-initial.mk).

Replacing HOST_GCC_INITIAL_CONF_OPTS with this for testing:
HOST_GCC_INITIAL_CONF_OPTS = \
	--build=x86_64-pc-linux-gnu \
	--host=x86_64-pc-linux-gnu \
	--target=$(GNU_TARGET_NAME) \
	--with-sysroot=$(STAGING_DIR) \
	--with-gmp=$(HOST_DIR) \
	--with-mpc=$(HOST_DIR) \
	--with-mpfr=$(HOST_DIR) \
	--with-pkgversion="Buildroot $(BR2_VERSION_FULL)" \
	--with-bugurl=http://bugs.buildroot.net/ \
	--enable-initfini-array \
	--disable-libssp \
	--disable-shared \
	--disable-threads \
	--disable-libatomic \
	--disable-decimal-float \
	--disable-libffi \
	--disable-libgomp \
	--disable-libitm \
	--disable-libmpx \
	--disable-libquadmath \
	--disable-libsanitizer \
	--without-headers \
	--with-newlib \
	--enable-languages=c, \
	--with-arch=mips32r3 --with-abi=32 --with-nan=legacy --with-fp-32=xx

With this I get the same failure as before. Does this successfully build for you?

After patching gcc-initial.mk to test I do:
make clean
make glibc

> 
> [1]
> https://sourceware.org/git/?p=glibc.git;a=blob;f=scripts/build-many-glibcs.
> py;h=5af6f369ae04027911b3407c64716dd1571eae6a;hb=HEAD

(In reply to James Hilliard from comment #8)
> (In reply to Adhemerval Zanella from comment #7)
> > (In reply to James Hilliard from comment #6)
> > > 
> > > Full commands:
> > > git clone https://github.com/buildroot/buildroot.git
> > > cd buildroot
> > > git checkout e4ecf82f99f53e55d51e6f74ae5021473aa2bb1d
> > > wget
> > > http://autobuild.buildroot.net/results/883/
> > > 883b171a856a63540908976592683527fdb21cd2/config
> > > mv config .config
> > > make glibc
> > 
> > Ok, with this one I can see the buildroot failure. It seems that it is
> > misconfiguring the stage1 gcc, where the libgcc.a generated is relying on
> > the libc for unwinding (thus why ld.so link is failing).
> > 
> > I mimic what build-many-glibcs.py [1] does (which is canonical way to build
> > complete toolchain for glibc) and build a stage1 on buildroot system with:
> > 
> > ---
> > ./configure \
> >   --prefix=/tmp/buildroot/output/host \
> >   --build=x86_64-pc-linux-gnu \
> >   --host=x86_64-pc-linux-gnu \
> >   --target=mips64el-glibc-linux-gnu \
> 
> This looks wrong, we aren't building for mips64el(which our autobuilders
> also indicate does not have this particular build failure).

Our script builds only one toolchain with multilib enabled (which I think it is not the case for buildroot).  In any case, for stage1 either mips64el-glibc-linux-gnu or mipsel-glibc-linux-gnu works (since for mips64el gcc still can generates -mabi=32 code).

> 
> >   --sysconfdir=/tmp/buildroot/output/host/etc \
> >   --localstatedir=/tmp/buildroot/output/host/var \
> >   --target=mipsel-buildroot-linux-gnu \
> 
> Setting target a second time?

I copy/paste from the stage1 config we use in your script and forget to remove the mips64el one, using only mipsel-buildroot-linux-gnu should be suffice.

> 
> >  
> > --with-sysroot=/tmp/buildroot/output/host/mipsel-buildroot-linux-gnu/sysroot
> > \
> >   --with-gmp=/tmp/buildroot/output/host \
> >   --with-mpc=/tmp/buildroot/output/host \
> >   --with-mpfr=/tmp/buildroot/output/host \
> >   --with-pkgversion="Buildroot 2022.08-383-ge4ecf82f99-dirty" \
> >   --with-bugurl=http://bugs.buildroot.net/ \
> >   --enable-initfini-array \
> >   --disable-libssp \
> >   --disable-shared \
> >   --disable-threads \
> >   --disable-libatomic \
> >   --disable-decimal-float \
> >   --disable-libffi \
> >   --disable-libgomp \
> >   --disable-libitm \
> >   --disable-libmpx \
> >   --disable-libquadmath \
> >   --disable-libsanitizer \
> >   --without-headers\
> >   --with-newlib \
> >   --enable-languages=c, \
> >   --with-arch=mips32r3 --with-abi=32 --with-nan=legacy --with-fp-32=xx
> > ---
> 
> I've attempted to make a build using this configuration but have not been
> able to get a working build.
> 
> > 
> > And with this stage1 gcc I could finish the glibc build. I am afraid you
> > will need to sort this out on buildroot stage1 configuration flags used on
> > gcc.
> 
> I've tested by patching our gcc stage1
> configure(package/gcc/gcc-initial/gcc-initial.mk).
> 
> Replacing HOST_GCC_INITIAL_CONF_OPTS with this for testing:
> HOST_GCC_INITIAL_CONF_OPTS = \
> 	--build=x86_64-pc-linux-gnu \
> 	--host=x86_64-pc-linux-gnu \
> 	--target=$(GNU_TARGET_NAME) \
> 	--with-sysroot=$(STAGING_DIR) \
> 	--with-gmp=$(HOST_DIR) \
> 	--with-mpc=$(HOST_DIR) \
> 	--with-mpfr=$(HOST_DIR) \
> 	--with-pkgversion="Buildroot $(BR2_VERSION_FULL)" \
> 	--with-bugurl=http://bugs.buildroot.net/ \
> 	--enable-initfini-array \
> 	--disable-libssp \
> 	--disable-shared \
> 	--disable-threads \
> 	--disable-libatomic \
> 	--disable-decimal-float \
> 	--disable-libffi \
> 	--disable-libgomp \
> 	--disable-libitm \
> 	--disable-libmpx \
> 	--disable-libquadmath \
> 	--disable-libsanitizer \
> 	--without-headers \
> 	--with-newlib \
> 	--enable-languages=c, \
> 	--with-arch=mips32r3 --with-abi=32 --with-nan=legacy --with-fp-32=xx
> 
> With this I get the same failure as before. Does this successfully build for
> you?
> 

I did not actually patches the buildroot build system, but rather rebuild the stage1 gcc at output/build/host-gcc-initial-11.3.0/build with the configuration, issued make install and rebuild the glibc (output/build/glibc-2.36-44-g2628500f5dff1dd99c49a09b418b3b1ea3a6b5d3/build).

It does show to work:

$ file elf/ld.so
elf/ld.so: ELF 32-bit LSB shared object, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, with debug_info, not stripped
$ ./elf/ld.so --version
ld.so (Buildroot) stable release version 2.36.
Copyright (C) 2022 Free Software Foundation, Inc.
[...]
$ ./elf/ld.so ./libc.so
GNU C Library (Buildroot) stable release version 2.36.
[...]

At least qemu mips usermode can actually run the resulting loader.

> After patching gcc-initial.mk to test I do:
> make clean
> make glibc
> 
> > 
> > [1]
> > https://sourceware.org/git/?p=glibc.git;a=blob;f=scripts/build-many-glibcs.
> > py;h=5af6f369ae04027911b3407c64716dd1571eae6a;hb=HEAD

I tried to hack the builroot system without much success, I also tried to mimic what build-many-glibcs.py does, but I keep seeing the build failure.

However, if I rebuild the gcc with my hacked config:

./configure --prefix=/tmp/buildroot/output/host --sysconfdir=/tmp/buildroot/output/host/etc --localstatedir=/tmp/buildroot/output/host/var --disable-gtk-doc --disable-gtk-doc-html --disable-doc --disable-docs --disable-documentation --disable-debug --with-xmlto=no --with-fop=no --disable-nls --disable-dependency-tracking --target=mipsel-buildroot-linux-gnu --with-sysroot=/tmp/buildroot/output/host/mipsel-buildroot-linux-gnu/sysroot --with-gnu-ld --disable-libssp --disable-multilib --disable-decimal-float --with-gmp=/tmp/buildroot/output/host --with-mpc=/tmp/buildroot/output/host --with-mpfr=/tmp/buildroot/output/host --with-pkgversion="Buildroot 2022.08-383-ge4ecf82f99-dirty" --with-bugurl=http://bugs.buildroot.net/ --without-zstd --disable-libquadmath --disable-libquadmath-support --without-isl --without-cloog --with-arch=mips32r3 --with-abi=32 --with-nan=legacy --with-fp-32=xx --enable-languages=c --enable-initfini-array --disable-libssp --disable-shared --without-headers --disable-threads --disable-libatomic --disable-decimal-float --disable-libffi --disable-libgomp --disable-libitm --disable-libmpx --disable-libquadmath --disable-libsanitizer --with-newlib

on the buildroot directory, reinstall it, and the glibc does finish. That's why I think there is something bogues on buildroot that I can't figure out.

(In reply to Adhemerval Zanella from comment #9)
> (In reply to James Hilliard from comment #8)
> > (In reply to Adhemerval Zanella from comment #7)
> > > (In reply to James Hilliard from comment #6)
> > > > 
> > > > Full commands:
> > > > git clone https://github.com/buildroot/buildroot.git
> > > > cd buildroot
> > > > git checkout e4ecf82f99f53e55d51e6f74ae5021473aa2bb1d
> > > > wget
> > > > http://autobuild.buildroot.net/results/883/
> > > > 883b171a856a63540908976592683527fdb21cd2/config
> > > > mv config .config
> > > > make glibc
> > > 
> > > Ok, with this one I can see the buildroot failure. It seems that it is
> > > misconfiguring the stage1 gcc, where the libgcc.a generated is relying on
> > > the libc for unwinding (thus why ld.so link is failing).
> > > 
> > > I mimic what build-many-glibcs.py [1] does (which is canonical way to build
> > > complete toolchain for glibc) and build a stage1 on buildroot system with:
> > > 
> > > ---
> > > ./configure \
> > >   --prefix=/tmp/buildroot/output/host \
> > >   --build=x86_64-pc-linux-gnu \
> > >   --host=x86_64-pc-linux-gnu \
> > >   --target=mips64el-glibc-linux-gnu \
> > 
> > This looks wrong, we aren't building for mips64el(which our autobuilders
> > also indicate does not have this particular build failure).
> 
> Our script builds only one toolchain with multilib enabled (which I think it
> is not the case for buildroot).  In any case, for stage1 either
> mips64el-glibc-linux-gnu or mipsel-glibc-linux-gnu works (since for mips64el
> gcc still can generates -mabi=32 code).

We're building with multilib disabled I think in buildroot here.

Maybe there's something in glibc broken for non-multilib builds?

> 
> > 
> > >   --sysconfdir=/tmp/buildroot/output/host/etc \
> > >   --localstatedir=/tmp/buildroot/output/host/var \
> > >   --target=mipsel-buildroot-linux-gnu \
> > 
> > Setting target a second time?
> 
> I copy/paste from the stage1 config we use in your script and forget to
> remove the mips64el one, using only mipsel-buildroot-linux-gnu should be
> suffice.
> 
> > 
> > >  
> > > --with-sysroot=/tmp/buildroot/output/host/mipsel-buildroot-linux-gnu/sysroot
> > > \
> > >   --with-gmp=/tmp/buildroot/output/host \
> > >   --with-mpc=/tmp/buildroot/output/host \
> > >   --with-mpfr=/tmp/buildroot/output/host \
> > >   --with-pkgversion="Buildroot 2022.08-383-ge4ecf82f99-dirty" \
> > >   --with-bugurl=http://bugs.buildroot.net/ \
> > >   --enable-initfini-array \
> > >   --disable-libssp \
> > >   --disable-shared \
> > >   --disable-threads \
> > >   --disable-libatomic \
> > >   --disable-decimal-float \
> > >   --disable-libffi \
> > >   --disable-libgomp \
> > >   --disable-libitm \
> > >   --disable-libmpx \
> > >   --disable-libquadmath \
> > >   --disable-libsanitizer \
> > >   --without-headers\
> > >   --with-newlib \
> > >   --enable-languages=c, \
> > >   --with-arch=mips32r3 --with-abi=32 --with-nan=legacy --with-fp-32=xx
> > > ---
> > 
> > I've attempted to make a build using this configuration but have not been
> > able to get a working build.
> > 
> > > 
> > > And with this stage1 gcc I could finish the glibc build. I am afraid you
> > > will need to sort this out on buildroot stage1 configuration flags used on
> > > gcc.
> > 
> > I've tested by patching our gcc stage1
> > configure(package/gcc/gcc-initial/gcc-initial.mk).
> > 
> > Replacing HOST_GCC_INITIAL_CONF_OPTS with this for testing:
> > HOST_GCC_INITIAL_CONF_OPTS = \
> > 	--build=x86_64-pc-linux-gnu \
> > 	--host=x86_64-pc-linux-gnu \
> > 	--target=$(GNU_TARGET_NAME) \
> > 	--with-sysroot=$(STAGING_DIR) \
> > 	--with-gmp=$(HOST_DIR) \
> > 	--with-mpc=$(HOST_DIR) \
> > 	--with-mpfr=$(HOST_DIR) \
> > 	--with-pkgversion="Buildroot $(BR2_VERSION_FULL)" \
> > 	--with-bugurl=http://bugs.buildroot.net/ \
> > 	--enable-initfini-array \
> > 	--disable-libssp \
> > 	--disable-shared \
> > 	--disable-threads \
> > 	--disable-libatomic \
> > 	--disable-decimal-float \
> > 	--disable-libffi \
> > 	--disable-libgomp \
> > 	--disable-libitm \
> > 	--disable-libmpx \
> > 	--disable-libquadmath \
> > 	--disable-libsanitizer \
> > 	--without-headers \
> > 	--with-newlib \
> > 	--enable-languages=c, \
> > 	--with-arch=mips32r3 --with-abi=32 --with-nan=legacy --with-fp-32=xx
> > 
> > With this I get the same failure as before. Does this successfully build for
> > you?
> > 
> 
> I did not actually patches the buildroot build system, but rather rebuild
> the stage1 gcc at output/build/host-gcc-initial-11.3.0/build with the
> configuration, issued make install and rebuild the glibc
> (output/build/glibc-2.36-44-g2628500f5dff1dd99c49a09b418b3b1ea3a6b5d3/build).
> 
> It does show to work:
> 
> $ file elf/ld.so
> elf/ld.so: ELF 32-bit LSB shared object, MIPS, MIPS32 rel2 version 1 (SYSV),
> dynamically linked, with debug_info, not stripped
> $ ./elf/ld.so --version
> ld.so (Buildroot) stable release version 2.36.
> Copyright (C) 2022 Free Software Foundation, Inc.
> [...]
> $ ./elf/ld.so ./libc.so
> GNU C Library (Buildroot) stable release version 2.36.
> [...]
> 
> At least qemu mips usermode can actually run the resulting loader.
> 
> > After patching gcc-initial.mk to test I do:
> > make clean
> > make glibc
> > 
> > > 
> > > [1]
> > > https://sourceware.org/git/?p=glibc.git;a=blob;f=scripts/build-many-glibcs.
> > > py;h=5af6f369ae04027911b3407c64716dd1571eae6a;hb=HEAD
> 
> I tried to hack the builroot system without much success, I also tried to
> mimic what build-many-glibcs.py does, but I keep seeing the build failure.
> 
> However, if I rebuild the gcc with my hacked config:
> 
> ./configure --prefix=/tmp/buildroot/output/host
> --sysconfdir=/tmp/buildroot/output/host/etc
> --localstatedir=/tmp/buildroot/output/host/var --disable-gtk-doc
> --disable-gtk-doc-html --disable-doc --disable-docs --disable-documentation
> --disable-debug --with-xmlto=no --with-fop=no --disable-nls
> --disable-dependency-tracking --target=mipsel-buildroot-linux-gnu
> --with-sysroot=/tmp/buildroot/output/host/mipsel-buildroot-linux-gnu/sysroot
> --with-gnu-ld --disable-libssp --disable-multilib --disable-decimal-float
> --with-gmp=/tmp/buildroot/output/host --with-mpc=/tmp/buildroot/output/host
> --with-mpfr=/tmp/buildroot/output/host --with-pkgversion="Buildroot
> 2022.08-383-ge4ecf82f99-dirty" --with-bugurl=http://bugs.buildroot.net/
> --without-zstd --disable-libquadmath --disable-libquadmath-support
> --without-isl --without-cloog --with-arch=mips32r3 --with-abi=32
> --with-nan=legacy --with-fp-32=xx --enable-languages=c
> --enable-initfini-array --disable-libssp --disable-shared --without-headers
> --disable-threads --disable-libatomic --disable-decimal-float
> --disable-libffi --disable-libgomp --disable-libitm --disable-libmpx
> --disable-libquadmath --disable-libsanitizer --with-newlib
> 
> on the buildroot directory, reinstall it, and the glibc does finish. That's
> why I think there is something bogues on buildroot that I can't figure out.

Yeah, so building manually like that tends to bypass a lot of our build environment and often ends up with built in host os utilities/dependencies getting pulled in instead of the intended buildroot toolchain versions.

So a build succeeding outside of our env like that may not really mean a whole lot in terms of it being a buildroot side bug as building manually may be using a totally different environment that bypasses/sidesteps a bug.

(In reply to Adhemerval Zanella from comment #7)
> Ok, with this one I can see the buildroot failure. It seems that it is
> misconfiguring the stage1 gcc, where the libgcc.a generated is relying on
> the libc for unwinding (thus why ld.so link is failing).

No, this is expected. The libgcc unwinder has depended on glibc symbols for many, many years. The unwinder cannot be linked into ld.so.

Someone needs to use ld tracing to figure out why __register_frame is pulled into the ld.so link.

(In reply to Florian Weimer from comment #11)
> (In reply to Adhemerval Zanella from comment #7)
> > Ok, with this one I can see the buildroot failure. It seems that it is
> > misconfiguring the stage1 gcc, where the libgcc.a generated is relying on
> > the libc for unwinding (thus why ld.so link is failing).
> 
> No, this is expected. The libgcc unwinder has depended on glibc symbols for
> many, many years. The unwinder cannot be linked into ld.so.
> 
> Someone needs to use ld tracing to figure out why __register_frame is pulled
> into the ld.so link.

What I am trying to say is buildroot generated stage1 compiler with libgcc.a for mipsle that is not what glibc expects.  The buildroot symbol trace for librtld.so shows:

$ /tmp/buildroot/output/host/mipsel-buildroot-linux-gnu/bin/ld [...] --trace-symbol=__register_frame
/tmp/buildroot/output/host/mipsel-buildroot-linux-gnu/bin/ld: /tmp/buildroot/output/host/lib/gcc/mipsel-buildroot-linux-gnu/11.3.0/libgcc.a(unwind-dw2-fde-dip.o): definition of __register_frame

However even the stage2 gcc11 from the build-many-glibc does not links against the unwinder:

$ mips64el-glibc-linux-gnu-ld -plugin [...] --trace-symbol=__register_frame
$ 

It does not container any unwinder routines:

$ ./bin/mips64el-glibc-linux-gnu-objdump -t ./lib/gcc/mips64el-glibc-linux-gnu/11.3.1/libgcc.a | grep unwind
$ 

It is in fact on libgcc_eh.a:

$ ./bin/mips64el-glibc-linux-gnu-objdump -t ./lib/gcc/mips64el-glibc-linux-gnu/11.3.1/libgcc_eh.a | grep unwind
unwind-dw2.o:     file format elf32-ntradlittlemips
00000000 l    df *ABS*  00000000 /home/azanella/toolchain/src/gcc/libgcc/unwind-dw2.c
unwind-dw2-fde-dip.o:     file format elf32-ntradlittlemips
00000000 l    df *ABS*  00000000 /home/azanella/toolchain/src/gcc/libgcc/unwind-dw2-fde.c
unwind-sjlj.o:     file format elf32-ntradlittlemips
unwind-c.o:     file format elf32-ntradlittlemips
00000000 l    df *ABS*  00000000 /home/azanella/toolchain/src/gcc/libgcc/unwind-pe.h

$ ./bin/mips64el-glibc-linux-gnu-objdump -t ./lib/gcc/mips64el-glibc-linux-gnu/11.3.1/libgcc_eh.a | grep __register_frame
00002090 g     F .text  000000d8 .hidden __register_frame_info_bases
00002168 g     F .text  000000d8 .hidden __register_frame_info
00002240 g     F .text  0000006c .hidden __register_frame
000022b0 g     F .text  000000b0 .hidden __register_frame_info_table_bases
00002360 g     F .text  000000b0 .hidden __register_frame_info_table
00002410 g     F .text  000000d0 .hidden __register_frame_table

I am not sure if this is a multilib issue.

And I just hacked build-many-glibcs.py to generate a mipsel-linux-gnu toolchain to mimic buildroot configuration:

diff --git a/scripts/build-many-glibcs.py b/scripts/build-many-glibcs.py
index da9b905900..ae55183568 100755
--- a/scripts/build-many-glibcs.py
+++ b/scripts/build-many-glibcs.py
@@ -283,12 +283,14 @@ class Context(object):
                                  'ccopts': '-mabi=32'},
                                 {'variant': 'n64-nan2008-soft',
                                  'ccopts': '-mabi=64'}])
+        self.add_config(arch='mipsel',
+                        os_name='linux-gnu',
+                        gcc_cfg=['--with-mips-plt', '--with-arch=mips32r3', '--with-abi=32',
+                                 '--with-nan=legacy', '--with-fp-32=xx', '--disable-multilib'])
         self.add_config(arch='mips64el',
                         os_name='linux-gnu',
                         gcc_cfg=['--with-mips-plt'],
                         glibcs=[{'variant': 'n32'},
-                                {'arch': 'mipsel',
-                                 'ccopts': '-mabi=32'},
                                 {'variant': 'n64',
                                  'ccopts': '-mabi=64'}])
         self.add_config(arch='mips64el',

And the bootstrap finished without any issue using gcc11 release branch, binutils 2.39, and glibc 2.36.  Checking the generated stage1 gcc, the libgcc.a does not have any __register_frame:

$ build/compilers/mipsel-linux-gnu$ ./binutils/binutils/objdump -t ./gcc/mipsel-glibc-linux-gnu/libgcc/libgcc.a | grep __register_frame
$
$ ./binutils/binutils/objdump -t ./gcc/mipsel-glibc-linux-gnu/libgcc/libgcc_eh.a | grep __register_frame
00001f9c g     F .text  000000e0 .hidden __register_frame_info_bases
0000207c g     F .text  000000e0 .hidden __register_frame_info
0000215c g     F .text  00000068 .hidden __register_frame
000021c4 g     F .text  000000c0 .hidden __register_frame_info_table_bases
00002284 g     F .text  000000c0 .hidden __register_frame_info_table
00002344 g     F .text  000000e0 .hidden __register_frame_table

So now I even more confident it is something on buildroot environment that is generating a wrong stage1 gcc build.

> So now I even more confident it is something on buildroot environment that
> is generating a wrong stage1 gcc build.

You can see the exact env being set during buildroot's configure stage and copy that for testing:

>>> host-gcc-initial 11.3.0 Configuring
mkdir -p /tmp/buildroot/output/build/host-gcc-initial-11.3.0/build
ln -sf ../configure /tmp/buildroot/output/build/host-gcc-initial-11.3.0/build/configure
(cd /tmp/buildroot/output/build/host-gcc-initial-11.3.0/build && rm -rf config.cache; PATH="/tmp/buildroot/output/host/bin:/tmp/buildroot/output/host/sbin:/home/buildroot/bin:/home/buildroot/.local/bin:/home/buildroot/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin" PKG_CONFIG="/tmp/buildroot/output/host/bin/pkg-config" PKG_CONFIG_SYSROOT_DIR="/" PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 PKG_CONFIG_ALLOW_SYSTEM_LIBS=1 PKG_CONFIG_LIBDIR="/tmp/buildroot/output/host/lib/pkgconfig:/tmp/buildroot/output/host/share/pkgconfig" AR="/usr/bin/ar" AS="/usr/bin/as" LD="/usr/bin/ld" NM="/usr/bin/nm" CC="/usr/bin/gcc" GCC="/usr/bin/gcc" CXX="/usr/bin/g++" CPP="/usr/bin/cpp" OBJCOPY="/usr/bin/objcopy" RANLIB="/usr/bin/ranlib" CPPFLAGS="-I/tmp/buildroot/output/host/include" CFLAGS="-O2 -I/tmp/buildroot/output/host/include" CXXFLAGS="-O2 -I/tmp/buildroot/output/host/include" LDFLAGS="-L/tmp/buildroot/output/host/lib -Wl,-rpath,/tmp/buildroot/output/host/lib" INTLTOOL_PERL=/usr/bin/perl CFLAGS="-O2 -I/tmp/buildroot/output/host/include" LDFLAGS="-L/tmp/buildroot/output/host/lib -Wl,-rpath,/tmp/buildroot/output/host/lib" MAKEINFO=missing CFLAGS_FOR_TARGET="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -O0 -g0 " CXXFLAGS_FOR_TARGET="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -O0 -g0 " AR_FOR_TARGET=gcc-ar NM_FOR_TARGET=gcc-nm RANLIB_FOR_TARGET=gcc-ranlib CONFIG_SITE=/dev/null ./configure --prefix="/tmp/buildroot/output/host" --sysconfdir="/tmp/buildroot/output/host/etc" --localstatedir="/tmp/buildroot/output/host/var" --enable-shared --disable-static --disable-gtk-doc --disable-gtk-doc-html --disable-doc --disable-docs --disable-documentation --disable-debug --with-xmlto=no --with-fop=no --disable-nls --disable-dependency-tracking  --target=mipsel-buildroot-linux-gnu --with-sysroot=/tmp/buildroot/output/host/mipsel-buildroot-linux-gnu/sysroot --enable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib --disable-decimal-float --enable-plugins --enable-lto --with-gmp=/tmp/buildroot/output/host --with-mpc=/tmp/buildroot/output/host --with-mpfr=/tmp/buildroot/output/host --with-pkgversion="Buildroot 2022.08-383-ge4ecf82f99" --with-bugurl="http://bugs.buildroot.net/" --without-zstd --disable-libquadmath --disable-libquadmath-support --enable-tls --enable-threads --without-isl --without-cloog --with-arch="mips32r3" --with-abi="32" --with-nan="legacy" --with-fp-32="xx" --enable-languages=c --disable-shared --without-headers --disable-threads --with-newlib --disable-largefile  )

Something different with the buildroot compilation environmental variables seems to be why your build is working. If you set them manually when running ./configure one gets the same failure as when building using buildroot.

This fails for example:
PATH="/tmp/buildroot/output/host/bin:/tmp/buildroot/output/host/sbin:/home/buildroot/bin:/home/buildroot/.local/bin:/home/buildroot/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin" PKG_CONFIG="/tmp/buildroot/output/host/bin/pkg-config" PKG_CONFIG_SYSROOT_DIR="/" PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 PKG_CONFIG_ALLOW_SYSTEM_LIBS=1 PKG_CONFIG_LIBDIR="/tmp/buildroot/output/host/lib/pkgconfig:/tmp/buildroot/output/host/share/pkgconfig" AR="/usr/bin/ar" AS="/usr/bin/as" LD="/usr/bin/ld" NM="/usr/bin/nm" CC="/usr/bin/gcc" GCC="/usr/bin/gcc" CXX="/usr/bin/g++" CPP="/usr/bin/cpp" OBJCOPY="/usr/bin/objcopy" RANLIB="/usr/bin/ranlib" CPPFLAGS="-I/tmp/buildroot/output/host/include" CFLAGS="-O2 -I/tmp/buildroot/output/host/include" CXXFLAGS="-O2 -I/tmp/buildroot/output/host/include" LDFLAGS="-L/tmp/buildroot/output/host/lib -Wl,-rpath,/tmp/buildroot/output/host/lib" INTLTOOL_PERL=/usr/bin/perl CFLAGS="-O2 -I/tmp/buildroot/output/host/include" LDFLAGS="-L/tmp/buildroot/output/host/lib -Wl,-rpath,/tmp/buildroot/output/host/lib" MAKEINFO=missing CFLAGS_FOR_TARGET="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -O0 -g0 " CXXFLAGS_FOR_TARGET="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -O0 -g0 " AR_FOR_TARGET=gcc-ar NM_FOR_TARGET=gcc-nm RANLIB_FOR_TARGET=gcc-ranlib CONFIG_SITE=/dev/null ./configure --prefix=/tmp/buildroot/output/host --sysconfdir=/tmp/buildroot/output/host/etc --localstatedir=/tmp/buildroot/output/host/var --disable-gtk-doc --disable-gtk-doc-html --disable-doc --disable-docs --disable-documentation --disable-debug --with-xmlto=no --with-fop=no --disable-nls --disable-dependency-tracking --target=mipsel-buildroot-linux-gnu --with-sysroot=/tmp/buildroot/output/host/mipsel-buildroot-linux-gnu/sysroot --with-gnu-ld --disable-libssp --disable-multilib --disable-decimal-float --with-gmp=/tmp/buildroot/output/host --with-mpc=/tmp/buildroot/output/host --with-mpfr=/tmp/buildroot/output/host --with-pkgversion="Buildroot 2022.08-383-ge4ecf82f99-dirty" --with-bugurl=http://bugs.buildroot.net/ --without-zstd --disable-libquadmath --disable-libquadmath-support --without-isl --without-cloog --with-arch=mips32r3 --with-abi=32 --with-nan=legacy --with-fp-32=xx --enable-languages=c --enable-initfini-array --disable-libssp --disable-shared --without-headers --disable-threads --disable-libatomic --disable-decimal-float --disable-libffi --disable-libgomp --disable-libitm --disable-libmpx --disable-libquadmath --disable-libsanitizer --with-newlib

(In reply to James Hilliard from comment #14)
> > So now I even more confident it is something on buildroot environment that
> > is generating a wrong stage1 gcc build.
> 
> 
> Something different with the buildroot compilation environmental variables
> seems to be why your build is working. If you set them manually when running
> ./configure one gets the same failure as when building using buildroot.
> 

I am sorry but you will need to figure out yourself what buildroot is doing
that is not expected here, since:

  1. glibc bootscript (build-many-glibcs.py) can bootstrap both mipsel-linux-gnu
     and mips64el-linux-gnu toolchain.

  2. Building manually on buildroot does not show the issue. 

If can use the build-many-glibcs.py to check the canonical way to bootstrap glibc.

(In reply to Adhemerval Zanella from comment #15)
> I am sorry but you will need to figure out yourself what buildroot is doing
> that is not expected here, since:
> 
>   1. glibc bootscript (build-many-glibcs.py) can bootstrap both
> mipsel-linux-gnu
>      and mips64el-linux-gnu toolchain.
> 
>   2. Building manually on buildroot does not show the issue. 
> 
> If can use the build-many-glibcs.py to check the canonical way to bootstrap
> glibc.

I think I've isolated the issue, the build fails when gcc target libs(CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET) are built with -O0, this also explains why it only reproduces when built in the buildroot env since we pass global optimization flags to all packages(and override as needed for packages with special requirements).

Overriding those to at least -O1 in gcc(similar to how we always override to at least -O1 in glibc) appears to fix the glibc build failure.

This seems strange, is it expected behavior to require gcc target libs to be built optimized?

Why would this only be an issue on a small subset of target architectures?

This also doesn't appear to be an issue that happens with uclibc or musl libc from what I can tell.

I can reproduce the issue with:

CFLAGS_FOR_TARGET='-O0' scripts/build-many-glibcs.py /var/tmp/glibc-tests compilers nios2-linux-gnu

It fails at compilers-nios2-linux-gnu glibc nios2-linux-gnu build with

/.../nios2-glibc-linux-gnu/bin/ld: /.../nios2-linux-gnu/glibc/nios2-linux-gnu/elf/librtld.os: in function `__register_frame':
/.../libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc'


I don't know if we can conclude if the problem is in GCC or in glibc. There is a GCC bug as well: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107728 but they answer with:

> This is not a GCC issue as __register_frame_table is declared as extern.
> This is almost definitely a glibc issue really.
> But I doubt glibc can be compiled at -O0 because of these issues.
> [Moreover], the functions are not optimized out at -O2 but rather they
> don't get pulled in glibc building because another function is referenced.
> 
> Either libgcc should be built with -fdata-sections -ffunction-sections or 
> glibc builds needs to be fixed such that it does not reference the function
> in the unwinder at -O0.  You need to look at the linker map to figure why
> the object file is being pulled into glibc at -O0 and not at -O2.
> But it is still a bug in glibc's ld.so really.

trace-symbol points to the same libgcc object that pulls in __register_frame: libgcc.a(unwind-dw2-fde-dip.o)

The question however is why unwind-dw2-fde-dip.o gets pulled in. The map file tells us that:

/.../libgcc.a(unwind-dw2.o)
                              /.../libgcc.a(_umoddi3.o) (_Unwind_Resume)
/.../libgcc.a(unwind-dw2-fde-dip.o)
                              /.../libgcc.a(unwind-dw2.o) (_Unwind_Find_FDE)

So my guess is that the problem really is in libgcc?

(In reply to Arnout Vandecappelle from comment #18)
> trace-symbol points to the same libgcc object that pulls in
> __register_frame: libgcc.a(unwind-dw2-fde-dip.o)
> 
> The question however is why unwind-dw2-fde-dip.o gets pulled in. The map
> file tells us that:
> 
> /.../libgcc.a(unwind-dw2.o)
>                               /.../libgcc.a(_umoddi3.o) (_Unwind_Resume)
> /.../libgcc.a(unwind-dw2-fde-dip.o)
>                               /.../libgcc.a(unwind-dw2.o) (_Unwind_Find_FDE)
> 
> So my guess is that the problem really is in libgcc?

It suggests that libgcc was built with -fexceptions, but without optimizations. We can't support that on the glibc side at present. The libgcc functions we use must not have a dependency on the unwinder.

Closing based on comment 19.