* [Bug libc/29621] librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc'
2022-09-27 19:44 [Bug libc/29621] New: librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc' james.hilliard1 at gmail dot com
@ 2022-09-27 19:44 ` james.hilliard1 at gmail dot com
2022-09-29 17:45 ` adhemerval.zanella at linaro dot org
` (20 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: james.hilliard1 at gmail dot com @ 2022-09-27 19:44 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29621
James Hilliard <james.hilliard1 at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |james.hilliard1 at gmail dot com
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libc/29621] librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc'
2022-09-27 19:44 [Bug libc/29621] New: librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc' james.hilliard1 at gmail dot com
2022-09-27 19:44 ` [Bug libc/29621] " james.hilliard1 at gmail dot com
@ 2022-09-29 17:45 ` adhemerval.zanella at linaro dot org
2022-09-29 19:51 ` james.hilliard1 at gmail dot com
` (19 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: adhemerval.zanella at linaro dot org @ 2022-09-29 17:45 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29621
Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |adhemerval.zanella at linaro dot o
| |rg
--- Comment #1 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
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
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libc/29621] librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc'
2022-09-27 19:44 [Bug libc/29621] New: librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc' james.hilliard1 at gmail dot com
2022-09-27 19:44 ` [Bug libc/29621] " james.hilliard1 at gmail dot com
2022-09-29 17:45 ` adhemerval.zanella at linaro dot org
@ 2022-09-29 19:51 ` james.hilliard1 at gmail dot com
2022-10-17 12:42 ` adhemerval.zanella at linaro dot org
` (18 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: james.hilliard1 at gmail dot com @ 2022-09-29 19:51 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29621
--- Comment #2 from James Hilliard <james.hilliard1 at gmail dot com> ---
(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
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libc/29621] librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc'
2022-09-27 19:44 [Bug libc/29621] New: librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc' james.hilliard1 at gmail dot com
` (2 preceding siblings ...)
2022-09-29 19:51 ` james.hilliard1 at gmail dot com
@ 2022-10-17 12:42 ` adhemerval.zanella at linaro dot org
2022-10-26 18:54 ` james.hilliard1 at gmail dot com
` (17 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: adhemerval.zanella at linaro dot org @ 2022-10-17 12:42 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29621
--- Comment #3 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
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
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libc/29621] librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc'
2022-09-27 19:44 [Bug libc/29621] New: librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc' james.hilliard1 at gmail dot com
` (3 preceding siblings ...)
2022-10-17 12:42 ` adhemerval.zanella at linaro dot org
@ 2022-10-26 18:54 ` james.hilliard1 at gmail dot com
2022-10-26 19:10 ` adhemerval.zanella at linaro dot org
` (16 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: james.hilliard1 at gmail dot com @ 2022-10-26 18:54 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29621
--- Comment #4 from James Hilliard <james.hilliard1 at gmail dot com> ---
(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.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libc/29621] librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc'
2022-09-27 19:44 [Bug libc/29621] New: librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc' james.hilliard1 at gmail dot com
` (4 preceding siblings ...)
2022-10-26 18:54 ` james.hilliard1 at gmail dot com
@ 2022-10-26 19:10 ` adhemerval.zanella at linaro dot org
2022-10-26 19:33 ` james.hilliard1 at gmail dot com
` (15 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: adhemerval.zanella at linaro dot org @ 2022-10-26 19:10 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29621
--- Comment #5 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(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
---
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libc/29621] librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc'
2022-09-27 19:44 [Bug libc/29621] New: librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc' james.hilliard1 at gmail dot com
` (5 preceding siblings ...)
2022-10-26 19:10 ` adhemerval.zanella at linaro dot org
@ 2022-10-26 19:33 ` james.hilliard1 at gmail dot com
2022-10-27 14:04 ` adhemerval.zanella at linaro dot org
` (14 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: james.hilliard1 at gmail dot com @ 2022-10-26 19:33 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29621
--- Comment #6 from James Hilliard <james.hilliard1 at gmail dot com> ---
(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
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libc/29621] librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc'
2022-09-27 19:44 [Bug libc/29621] New: librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc' james.hilliard1 at gmail dot com
` (6 preceding siblings ...)
2022-10-26 19:33 ` james.hilliard1 at gmail dot com
@ 2022-10-27 14:04 ` adhemerval.zanella at linaro dot org
2022-10-27 19:57 ` james.hilliard1 at gmail dot com
` (13 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: adhemerval.zanella at linaro dot org @ 2022-10-27 14:04 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29621
--- Comment #7 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(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
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libc/29621] librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc'
2022-09-27 19:44 [Bug libc/29621] New: librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc' james.hilliard1 at gmail dot com
` (7 preceding siblings ...)
2022-10-27 14:04 ` adhemerval.zanella at linaro dot org
@ 2022-10-27 19:57 ` james.hilliard1 at gmail dot com
2022-10-27 21:05 ` adhemerval.zanella at linaro dot org
` (12 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: james.hilliard1 at gmail dot com @ 2022-10-27 19:57 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29621
--- Comment #8 from James Hilliard <james.hilliard1 at gmail dot com> ---
(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
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libc/29621] librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc'
2022-09-27 19:44 [Bug libc/29621] New: librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc' james.hilliard1 at gmail dot com
` (8 preceding siblings ...)
2022-10-27 19:57 ` james.hilliard1 at gmail dot com
@ 2022-10-27 21:05 ` adhemerval.zanella at linaro dot org
2022-10-27 21:35 ` james.hilliard1 at gmail dot com
` (11 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: adhemerval.zanella at linaro dot org @ 2022-10-27 21:05 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29621
--- Comment #9 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(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.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libc/29621] librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc'
2022-09-27 19:44 [Bug libc/29621] New: librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc' james.hilliard1 at gmail dot com
` (9 preceding siblings ...)
2022-10-27 21:05 ` adhemerval.zanella at linaro dot org
@ 2022-10-27 21:35 ` james.hilliard1 at gmail dot com
2022-10-28 5:28 ` fweimer at redhat dot com
` (10 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: james.hilliard1 at gmail dot com @ 2022-10-27 21:35 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29621
--- Comment #10 from James Hilliard <james.hilliard1 at gmail dot com> ---
(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.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libc/29621] librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc'
2022-09-27 19:44 [Bug libc/29621] New: librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc' james.hilliard1 at gmail dot com
` (10 preceding siblings ...)
2022-10-27 21:35 ` james.hilliard1 at gmail dot com
@ 2022-10-28 5:28 ` fweimer at redhat dot com
2022-10-28 13:19 ` adhemerval.zanella at linaro dot org
` (9 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: fweimer at redhat dot com @ 2022-10-28 5:28 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29621
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fweimer at redhat dot com
--- Comment #11 from Florian Weimer <fweimer at redhat dot com> ---
(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.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libc/29621] librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc'
2022-09-27 19:44 [Bug libc/29621] New: librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc' james.hilliard1 at gmail dot com
` (11 preceding siblings ...)
2022-10-28 5:28 ` fweimer at redhat dot com
@ 2022-10-28 13:19 ` adhemerval.zanella at linaro dot org
2022-10-28 13:36 ` adhemerval.zanella at linaro dot org
` (8 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: adhemerval.zanella at linaro dot org @ 2022-10-28 13:19 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29621
--- Comment #12 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(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.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libc/29621] librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc'
2022-09-27 19:44 [Bug libc/29621] New: librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc' james.hilliard1 at gmail dot com
` (12 preceding siblings ...)
2022-10-28 13:19 ` adhemerval.zanella at linaro dot org
@ 2022-10-28 13:36 ` adhemerval.zanella at linaro dot org
2022-10-28 16:18 ` james.hilliard1 at gmail dot com
` (7 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: adhemerval.zanella at linaro dot org @ 2022-10-28 13:36 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29621
--- Comment #13 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
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.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libc/29621] librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc'
2022-09-27 19:44 [Bug libc/29621] New: librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc' james.hilliard1 at gmail dot com
` (13 preceding siblings ...)
2022-10-28 13:36 ` adhemerval.zanella at linaro dot org
@ 2022-10-28 16:18 ` james.hilliard1 at gmail dot com
2022-10-28 16:32 ` adhemerval.zanella at linaro dot org
` (6 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: james.hilliard1 at gmail dot com @ 2022-10-28 16:18 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29621
--- Comment #14 from James Hilliard <james.hilliard1 at gmail dot com> ---
> 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
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libc/29621] librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc'
2022-09-27 19:44 [Bug libc/29621] New: librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc' james.hilliard1 at gmail dot com
` (14 preceding siblings ...)
2022-10-28 16:18 ` james.hilliard1 at gmail dot com
@ 2022-10-28 16:32 ` adhemerval.zanella at linaro dot org
2022-10-28 21:23 ` james.hilliard1 at gmail dot com
` (5 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: adhemerval.zanella at linaro dot org @ 2022-10-28 16:32 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29621
--- Comment #15 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(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.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libc/29621] librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc'
2022-09-27 19:44 [Bug libc/29621] New: librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc' james.hilliard1 at gmail dot com
` (15 preceding siblings ...)
2022-10-28 16:32 ` adhemerval.zanella at linaro dot org
@ 2022-10-28 21:23 ` james.hilliard1 at gmail dot com
2022-11-24 17:01 ` arnout at mind dot be
` (4 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: james.hilliard1 at gmail dot com @ 2022-10-28 21:23 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29621
--- Comment #16 from James Hilliard <james.hilliard1 at gmail dot com> ---
(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.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libc/29621] librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc'
2022-09-27 19:44 [Bug libc/29621] New: librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc' james.hilliard1 at gmail dot com
` (16 preceding siblings ...)
2022-10-28 21:23 ` james.hilliard1 at gmail dot com
@ 2022-11-24 17:01 ` arnout at mind dot be
2022-11-24 17:21 ` arnout at mind dot be
` (3 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: arnout at mind dot be @ 2022-11-24 17:01 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29621
Arnout Vandecappelle <arnout at mind dot be> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |arnout at mind dot be
--- Comment #17 from Arnout Vandecappelle <arnout at mind dot be> ---
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.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libc/29621] librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc'
2022-09-27 19:44 [Bug libc/29621] New: librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc' james.hilliard1 at gmail dot com
` (17 preceding siblings ...)
2022-11-24 17:01 ` arnout at mind dot be
@ 2022-11-24 17:21 ` arnout at mind dot be
2022-11-24 17:27 ` fweimer at redhat dot com
` (2 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: arnout at mind dot be @ 2022-11-24 17:21 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29621
--- Comment #18 from Arnout Vandecappelle <arnout at mind dot be> ---
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?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libc/29621] librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc'
2022-09-27 19:44 [Bug libc/29621] New: librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc' james.hilliard1 at gmail dot com
` (18 preceding siblings ...)
2022-11-24 17:21 ` arnout at mind dot be
@ 2022-11-24 17:27 ` fweimer at redhat dot com
2023-08-07 9:37 ` sam at gentoo dot org
2024-01-11 9:41 ` fweimer at redhat dot com
21 siblings, 0 replies; 23+ messages in thread
From: fweimer at redhat dot com @ 2022-11-24 17:27 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29621
--- Comment #19 from Florian Weimer <fweimer at redhat dot com> ---
(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.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libc/29621] librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc'
2022-09-27 19:44 [Bug libc/29621] New: librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc' james.hilliard1 at gmail dot com
` (19 preceding siblings ...)
2022-11-24 17:27 ` fweimer at redhat dot com
@ 2023-08-07 9:37 ` sam at gentoo dot org
2024-01-11 9:41 ` fweimer at redhat dot com
21 siblings, 0 replies; 23+ messages in thread
From: sam at gentoo dot org @ 2023-08-07 9:37 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29621
Sam James <sam at gentoo dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sam at gentoo dot org
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libc/29621] librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc'
2022-09-27 19:44 [Bug libc/29621] New: librtld.os: in function `__register_frame': libgcc/unwind-dw2-fde.c:136: undefined reference to `malloc' james.hilliard1 at gmail dot com
` (20 preceding siblings ...)
2023-08-07 9:37 ` sam at gentoo dot org
@ 2024-01-11 9:41 ` fweimer at redhat dot com
21 siblings, 0 replies; 23+ messages in thread
From: fweimer at redhat dot com @ 2024-01-11 9:41 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29621
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #20 from Florian Weimer <fweimer at redhat dot com> ---
Closing based on comment 19.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 23+ messages in thread