Summary: | <sys-devel/binutils-2.36-r1 : gold is not compatible to sys-devel/gcc-11.1.0's dwarf-5, causes random SIGSEGVs | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Steffen Hau <steffen> |
Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | herrtimson, sam, tanekliang |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
URL: | https://sourceware.org/PR27246 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 813762 | ||
Bug Blocks: | 732706 | ||
Attachments: |
build.log
gcc differing objects between stage 2 and 3 gcc-11-unstable-bug-788661.tar.gz libstdc++ stage{2,3} config.log |
Description
Steffen Hau
2021-05-06 23:45:34 UTC
Created attachment 706434 [details]
build.log
- try vanilla CFLAGS? Any difference? - what about if you disable gold? (In reply to Sam James from comment #2) > - try vanilla CFLAGS? Any difference? > - what about if you disable gold? These look very vanilla for me: CFLAGS="-march=native -pipe -O2" CXXFLAGS="-march=native -pipe -O2" Do you want me to test any specific CFLAGS? GCC compared object files, at that stage no linker is involved afaik. But I will give it a try, if you would like to share any suggestions regarding *FLAGS I would be thankful. (In reply to Steffen Hau from comment #3) > (In reply to Sam James from comment #2) > > - try vanilla CFLAGS? Any difference? > > - what about if you disable gold? > > These look very vanilla for me: > CFLAGS="-march=native -pipe -O2" > CXXFLAGS="-march=native -pipe -O2" > I missed the specific part at the bottom ;) > Do you want me to test any specific CFLAGS? > I’ll let slyfox suggest things rather than guess for now, but if you’re bored, completely vanilla LDFLAGS just in case (given that GCC will build a compiler to use in subsequent stages)? > > GCC compared object files, at that stage no linker is involved afaik. > See above. But maybe I’m misremembering which stage that is in. > But I will give it a try, if you would like to share any suggestions > regarding *FLAGS I would be thankful. Please attach one diffing object file from stage2 and stage3 for comparison. Created attachment 706470 [details]
gcc differing objects between stage 2 and 3
(In reply to Sergei Trofimovich from comment #5) > Please attach one diffing object file from stage2 and stage3 for comparison. Let me know if you need more object files to check. Did you try to rebuild GCC 11.1.0 after it has been emerged with GCC 11.1.0 being the active compiler? (In reply to Steffen Hau from comment #7) > (In reply to Sergei Trofimovich from comment #5) > > Please attach one diffing object file from stage2 and stage3 for comparison. > > Let me know if you need more object files to check. Thank you! Will do. I'll need some time to run a gcc-specific diff locally. At lest so far generated code is identical: $ diff -u <(h objdump -d stage2-floating_to_chars.o) <(h objdump -d stage3-floating_to_chars.o) --- /dev/fd/63 2021-05-07 18:10:06.108739068 +0100 +++ /dev/fd/62 2021-05-07 18:10:06.108739068 +0100 @@ -1,5 +1,5 @@ -stage2-floating_to_chars.o: file format elf32-i386 +stage3-floating_to_chars.o: file format elf32-i386 > Did you try to rebuild GCC 11.1.0 after it has been emerged with GCC 11.1.0 > being the active compiler? Works fine for me here, but it's a USE=-lto system. I'll try USE=lto in a chroot. Source compiler should not matter as stage2/3 should be build by locale gcc-11. gcc uses the following tool to compare files (nothing complicated, phew): from build.log: checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 from Makefile.in: do-compare = @do_compare@ ... compare: .... echo Comparing stages 2 and 3; \ sed=`echo stage3 | sed 's,^stage,,;s,.,.,g'`; \ files=`find stage3-* -name "*$(objext)" -print | \ sed -n s,^stage$$sed-,,p`; \ for file in $${files} ${extra-compare}; do \ f1=$$r/stage2-$$file; f2=$$r/stage3-$$file; \ if test ! -f $$f1; then continue; fi; \ $(do-compare) > /dev/null 2>&1; \ if test $$? -eq 1; then \ case $$file in \ @compare_exclusions@) \ echo warning: $$file differs ;; \ *) \ echo $$file differs >> .bad_compare ;; \ Thus these should be byte-identical (modulo ELF's 16-byte magic+flags). But they are obviously different for you. Looking at first different lines of `readelf -W -a`: [23] .text._ZN12_GLOBAL__N_13ryuL9log10Pow2Ei.part.0 PROGBITS 00000000 000170 00002b 00 AX 0 0 16 [24] .rel.text._ZN12_GLOBAL__N_13ryuL9log10Pow2Ei.part.0 REL 00000000 066c64 000030 08 I 239 23 4 [23] .text._ZN12_GLOBAL__N_13ryuL9log10Pow2Ei.part.0 PROGBITS 00000000 000170 00002b 00 AX 0 0 16 [24] .rel.text._ZN12_GLOBAL__N_13ryuL9log10Pow2Ei.part.0 REL 00000000 066c40 000030 08 I 239 23 4 Note the file offset: 066c40 / 066c64. Stripping files generates identical binaries. This means gcc generates non-deterministic debug info for your case. Interestingly only for -m32 case. It might be gcc or might be binutils. We will need to narrow it down. Can you expand -march=native for your system? Via something like https://wiki.gentoo.org/wiki/Gcc-ICE-reporting-guide#Expand_-march.3Dnative.2C_exact_gcc_version_and_other_system-specific_options (In reply to Sergei Trofimovich from comment #8) > Thank you! Will do. I'll need some time to run a gcc-specific diff locally. > At lest so far generated code is identical: > > $ diff -u <(h objdump -d stage2-floating_to_chars.o) <(h objdump -d > stage3-floating_to_chars.o) > --- /dev/fd/63 2021-05-07 18:10:06.108739068 +0100 > +++ /dev/fd/62 2021-05-07 18:10:06.108739068 +0100 > @@ -1,5 +1,5 @@ > > -stage2-floating_to_chars.o: file format elf32-i386 > +stage3-floating_to_chars.o: file format elf32-i386 > > > Did you try to rebuild GCC 11.1.0 after it has been emerged with GCC 11.1.0 > > being the active compiler? > > Works fine for me here, but it's a USE=-lto system. I'll try USE=lto in a > chroot. > > Source compiler should not matter as stage2/3 should be build by locale > gcc-11. I thought that lto use flag is to make LTO feature available, I didn't know that lto is used for bootstrapping when use flag is enabled. (In reply to Sergei Trofimovich from comment #9) > This means gcc generates non-deterministic debug info for your case. > Interestingly only for -m32 case. > It might be gcc or might be binutils. We will need to narrow it down. Ok, let me know if I can help. > > Can you expand -march=native for your system? arch=skylake; for t in param target; do cmd="gcc -Q -O2 -march=$arch --help=$t"; diff -U0 <(LANG=C $cmd) <(LANG=C $cmd -march=native); done --- /dev/fd/63 2021-05-07 20:35:46.849957140 +0200 +++ /dev/fd/62 2021-05-07 20:35:46.850957157 +0200 @@ -84,2 +84,2 @@ - --param=l1-cache-size= 64 - --param=l2-cache-size= 512 + --param=l1-cache-size= 32 + --param=l2-cache-size= 6144 --- /dev/fd/63 2021-05-07 20:35:46.872957519 +0200 +++ /dev/fd/62 2021-05-07 20:35:46.872957519 +0200 @@ -12 +12 @@ - -mabm [disabled] + -mabm [enabled] For reference, here is also the complete argument list when -march=native is used: gcc -march=native -E -v - </dev/null 2>&1 | grep cc1 /usr/libexec/gcc/x86_64-pc-linux-gnu/11.1.0/cc1 -E -quiet -v - -march=skylake -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -mno-sse4a -mno-fma4 -mno-xop -mfma -mno-avx512f -mbmi -mbmi2 -maes -mpclmul -mno-avx512vl -mno-avx512bw -mno-avx512dq -mno-avx512cd -mno-avx512er -mno-avx512pf -mno-avx512vbmi -mno-avx512ifma -mno-avx5124vnniw -mno-avx5124fmaps -mno-avx512vpopcntdq -mno-avx512vbmi2 -mno-gfni -mno-vpclmulqdq -mno-avx512vnni -mno-avx512bitalg -mno-avx512bf16 -mno-avx512vp2intersect -mno-3dnow -madx -mabm -mno-cldemote -mclflushopt -mno-clwb -mno-clzero -mcx16 -mno-enqcmd -mf16c -mfsgsbase -mfxsr -mno-hle -msahf -mno-lwp -mlzcnt -mmovbe -mno-movdir64b -mno-movdiri -mno-mwaitx -mno-pconfig -mno-pku -mno-prefetchwt1 -mprfchw -mno-ptwrite -mno-rdpid -mrdrnd -mrdseed -mno-rtm -mno-serialize -msgx -mno-sha -mno-shstk -mno-tbm -mno-tsxldtrk -mno-vaes -mno-waitpkg -mno-wbnoinvd -mxsave -mxsavec -mxsaveopt -mxsaves -mno-amx-tile -mno-amx-int8 -mno-amx-bf16 -mno-uintr -mno-hreset -mno-kl -mno-widekl -mno-avxvnni --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=skylake -dumpbase - (In reply to Steffen Hau from comment #10) > (In reply to Sergei Trofimovich from comment #8) > > Thank you! Will do. I'll need some time to run a gcc-specific diff locally. > > At lest so far generated code is identical: > > > > $ diff -u <(h objdump -d stage2-floating_to_chars.o) <(h objdump -d > > stage3-floating_to_chars.o) > > --- /dev/fd/63 2021-05-07 18:10:06.108739068 +0100 > > +++ /dev/fd/62 2021-05-07 18:10:06.108739068 +0100 > > @@ -1,5 +1,5 @@ > > > > -stage2-floating_to_chars.o: file format elf32-i386 > > +stage3-floating_to_chars.o: file format elf32-i386 > > > > > Did you try to rebuild GCC 11.1.0 after it has been emerged with GCC 11.1.0 > > > being the active compiler? > > > > Works fine for me here, but it's a USE=-lto system. I'll try USE=lto in a > > chroot. > > > > Source compiler should not matter as stage2/3 should be build by locale > > gcc-11. > I thought that lto use flag is to make LTO feature available, I didn't know > that lto is used for bootstrapping when use flag is enabled. Long ago USE=lto used to enable gcc's lto backend. Nowadays lto backend is always enabled. USE=lto (similar to other packages) enables bootstra-lto. > (In reply to Sergei Trofimovich from comment #9) > > This means gcc generates non-deterministic debug info for your case. > > Interestingly only for -m32 case. > > It might be gcc or might be binutils. We will need to narrow it down. > Ok, let me know if I can help. > > > > > Can you expand -march=native for your system? > arch=skylake; for t in param target; do cmd="gcc -Q -O2 -march=$arch > --help=$t"; diff -U0 <(LANG=C $cmd) <(LANG=C $cmd -march=native); done > --- /dev/fd/63 2021-05-07 20:35:46.849957140 +0200 > +++ /dev/fd/62 2021-05-07 20:35:46.850957157 +0200 > @@ -84,2 +84,2 @@ > - --param=l1-cache-size= 64 > - --param=l2-cache-size= 512 > + --param=l1-cache-size= 32 > + --param=l2-cache-size= 6144 > --- /dev/fd/63 2021-05-07 20:35:46.872957519 +0200 > +++ /dev/fd/62 2021-05-07 20:35:46.872957519 +0200 > @@ -12 +12 @@ > - -mabm [disabled] > + -mabm [enabled] > > For reference, here is also the complete argument list when -march=native is > used: > gcc -march=native -E -v - </dev/null 2>&1 | grep cc1 > /usr/libexec/gcc/x86_64-pc-linux-gnu/11.1.0/cc1 -E -quiet -v - > -march=skylake -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 > -mavx -mavx2 -mno-sse4a -mno-fma4 -mno-xop -mfma -mno-avx512f -mbmi -mbmi2 > -maes -mpclmul -mno-avx512vl -mno-avx512bw -mno-avx512dq -mno-avx512cd > -mno-avx512er -mno-avx512pf -mno-avx512vbmi -mno-avx512ifma > -mno-avx5124vnniw -mno-avx5124fmaps -mno-avx512vpopcntdq -mno-avx512vbmi2 > -mno-gfni -mno-vpclmulqdq -mno-avx512vnni -mno-avx512bitalg -mno-avx512bf16 > -mno-avx512vp2intersect -mno-3dnow -madx -mabm -mno-cldemote -mclflushopt > -mno-clwb -mno-clzero -mcx16 -mno-enqcmd -mf16c -mfsgsbase -mfxsr -mno-hle > -msahf -mno-lwp -mlzcnt -mmovbe -mno-movdir64b -mno-movdiri -mno-mwaitx > -mno-pconfig -mno-pku -mno-prefetchwt1 -mprfchw -mno-ptwrite -mno-rdpid > -mrdrnd -mrdseed -mno-rtm -mno-serialize -msgx -mno-sha -mno-shstk -mno-tbm > -mno-tsxldtrk -mno-vaes -mno-waitpkg -mno-wbnoinvd -mxsave -mxsavec > -mxsaveopt -mxsaves -mno-amx-tile -mno-amx-int8 -mno-amx-bf16 -mno-uintr > -mno-hreset -mno-kl -mno-widekl -mno-avxvnni --param l1-cache-size=32 > --param l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=skylake > -dumpbase - Aha, I tried to extract a small bit of libstdc and tried to compile it with your -march= and other options. I don't see a fluctuation of output: $ ./mk.bash 008de0f156109084c45f59f73b651cd92708edc0 floating_to_chars.o1 008de0f156109084c45f59f73b651cd92708edc0 floating_to_chars.o2 008de0f156109084c45f59f73b651cd92708edc0 floating_to_chars.o3 There is a tiny chance that headers are somehow different at build (or other bugs I introduced by accident). I wonder if the minimal test will fail for you. I'll attach a tarball with test in a second. Created attachment 706560 [details]
gcc-11-unstable-bug-788661.tar.gz
./mk.bash 8a1a7e096786ca718925ff445b38725673557420 floating_to_chars.o1 8a1a7e096786ca718925ff445b38725673557420 floating_to_chars.o2 8a1a7e096786ca718925ff445b38725673557420 floating_to_chars.o3 Is there a difference in mk.bash I can't spot at the lines creating o1 and o2? As someone had binutils in mind: they were updated (2.35.2 -> 2.36.1-r1) in the same merge where gcc 11.1.0 was installed. (In reply to Steffen Hau from comment #13) > ./mk.bash > 8a1a7e096786ca718925ff445b38725673557420 floating_to_chars.o1 > 8a1a7e096786ca718925ff445b38725673557420 floating_to_chars.o2 > 8a1a7e096786ca718925ff445b38725673557420 floating_to_chars.o3 > > Is there a difference in mk.bash I can't spot at the lines creating o1 and > o2? They should be the same. I extracted all calls from your build log. > As someone had binutils in mind: they were updated (2.35.2 -> 2.36.1-r1) in > the same merge where gcc 11.1.0 was installed. Do you know the ordering? $ qlop -muv gcc binutils should show it. In theory gcc might have embedded binutils-based property into one of stages, but not the other (normally it should not). I also noticed that your stage2 file contains 'tmpnam' symbol in .debug_str, while stage3 does not. I wonder if libstdc++ for stage2/3 detected different value of _GLIBCXX_USE_TMPNAM libstdc++-v3/include/c_global/cstdio:#if _GLIBCXX_USE_TMPNAM libstdc++-v3/include/c_global/cstdio- using ::tmpnam; libstdc++-v3/include/c_global/cstdio-#endif It should be visible in config.h of libstdc++-v3. Or on config.log Your build.log is curiously inconsistent about it: $ cat sys-devel-gcc-11.1.0_build.log | fgrep tmpnam checking for tmpnam... config.status: creating Makefile checking for tmpnam... yes checking for tmpnam... no checking for tmpnam... yes checking for tmpnam... yes checking for tmpnam... no checking for tmpnam... yes checking for tmpnam... yes checking for tmpnam... no checking for tmpnam... no But it might be just parallel output problem. Mine is full of garbage, but at least it never says `no`: $ cat sys-devel:gcc-11.1.0:20210427-173430.log | fgrep tmpnam checking for tmpnam... yes checking for vsprintf... checking for tmpnam... yes checking for tmpnam... mv -f .deps/affinity-fmt.Tpo .deps/affinity-fmt.Plo checking for tmpnam... yes checking stdio.h usability... checking for tmpnam... yes checking for tmpnam... /bin/bash .... checking for tmpnam... yes checking for tmpnam... 4 checking for tmpnam... yes checking for tmpnam... yes (In reply to Sergei Trofimovich from comment #14) > (In reply to Steffen Hau from comment #13) > > ./mk.bash > > 8a1a7e096786ca718925ff445b38725673557420 floating_to_chars.o1 > > 8a1a7e096786ca718925ff445b38725673557420 floating_to_chars.o2 > > 8a1a7e096786ca718925ff445b38725673557420 floating_to_chars.o3 > > > > Is there a difference in mk.bash I can't spot at the lines creating o1 and > > o2? > > They should be the same. I extracted all calls from your build log. > > > As someone had binutils in mind: they were updated (2.35.2 -> 2.36.1-r1) in > > the same merge where gcc 11.1.0 was installed. > > Do you know the ordering? > $ qlop -muv gcc binutils > should show it. emerge -uvDU 2021-05-02T00:04:49 >>> sys-devel/binutils-2.36.1-r1 2021-05-02T00:10:07 >>> sys-devel/gcc-11.1.0 emerge --depclean 2021-05-02T21:38:30 <<< sys-devel/gcc-10.3.0 2021-05-02T21:38:45 <<< sys-devel/binutils-2.35.2 emerge -ve @world 2021-05-04T02:07:45 >>> sys-devel/binutils-2.36.1-r1 2021-05-04T02:12:29 failed sys-devel/gcc-11.1.0 (In reply to Sergei Trofimovich from comment #15) > I also noticed that your stage2 file contains 'tmpnam' symbol in .debug_str, > while stage3 does not. > > I wonder if libstdc++ for stage2/3 detected different value of > _GLIBCXX_USE_TMPNAM > > libstdc++-v3/include/c_global/cstdio:#if _GLIBCXX_USE_TMPNAM > libstdc++-v3/include/c_global/cstdio- using ::tmpnam; > libstdc++-v3/include/c_global/cstdio-#endif > > It should be visible in config.h of libstdc++-v3. Or on config.log > > Your build.log is curiously inconsistent about it: > > $ cat sys-devel-gcc-11.1.0_build.log | fgrep tmpnam > checking for tmpnam... config.status: creating Makefile > checking for tmpnam... yes > checking for tmpnam... no > checking for tmpnam... yes > checking for tmpnam... yes > checking for tmpnam... no > checking for tmpnam... yes > checking for tmpnam... yes > checking for tmpnam... no > checking for tmpnam... no > > But it might be just parallel output problem. Mine is full of garbage, but > at least it never says `no`: > > $ cat sys-devel:gcc-11.1.0:20210427-173430.log | fgrep tmpnam > checking for tmpnam... yes > checking for vsprintf... checking for tmpnam... yes > checking for tmpnam... mv -f .deps/affinity-fmt.Tpo .deps/affinity-fmt.Plo > checking for tmpnam... yes > checking stdio.h usability... checking for tmpnam... yes > checking for tmpnam... /bin/bash .... > checking for tmpnam... yes > checking for tmpnam... 4 > checking for tmpnam... yes > checking for tmpnam... yes This exceeds my knowledge. Should I tar the complete build dir so that you can have a look into it? I can send you a download link. As you mentioned glibc, the last glibc merges: emerge -uvDU @world 2021-04-14T09:33:21 >>> sys-libs/glibc-2.33 emerge -ve @world 2021-05-04T04:37:33 >>> sys-libs/glibc-2.33 > > $ cat sys-devel:gcc-11.1.0:20210427-173430.log | fgrep tmpnam
> > checking for tmpnam... yes
> > checking for vsprintf... checking for tmpnam... yes
> > checking for tmpnam... mv -f .deps/affinity-fmt.Tpo .deps/affinity-fmt.Plo
> > checking for tmpnam... yes
> > checking stdio.h usability... checking for tmpnam... yes
> > checking for tmpnam... /bin/bash ....
> > checking for tmpnam... yes
> > checking for tmpnam... 4
> > checking for tmpnam... yes
> > checking for tmpnam... yes
> This exceeds my knowledge. Should I tar the complete build dir so that you
> can have a look into it? I can send you a download link.
`config.log` from all directories should be sufficient. `tmpnam` is a simple link test that ries to link something like
#include <stdio.h>
int main() { char *tmp = tmpnam(NULL);
to detect `tmpnam` presence. We need to find a `config.log` that failed to link it and reported broken tmpnam.
diff -Naur stage2-libstdc++-32bit-config.log stage3-libstdc++-32bit-config.log [snip] configure:21172: checking for tmpnam -configure:21210: /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/xgcc -shared-libgcc -B/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc -nostdinc++ -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux-gnu/32/libstdc++-v3/src -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -fno-checking -m32 -o conftest -g -march=native -pipe -O2 -D_GNU_SOURCE -fno-exceptions conftest.cpp >&5 -/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/temp/cc2GI8iw.o:conftest.cpp:function main: warning: the use of `tmpnam' is dangerous, better use `mkstemp' -configure:21210: $? = 0 -configure:21226: result: yes +configure:21210: /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/xgcc -shared-libgcc -B/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc -nostdinc++ -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux-gnu/32/libstdc++-v3/src -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -fchecking=1 -m32 -o conftest -g -march=native -pipe -O2 -D_GNU_SOURCE -fno-exceptions conftest.cpp >&5 +collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped +compilation terminated. +configure:21210: $? = 1 This is the difference between the compiler arguments: @@ -11,7 +11,7 @@ /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include --fno-checking +-fchecking=1 I'll attach both config.logs. Created attachment 706617 [details]
libstdc++ stage{2,3} config.log
(In reply to Steffen Hau from comment #19) > diff -Naur stage2-libstdc++-32bit-config.log > stage3-libstdc++-32bit-config.log > [snip] > configure:21172: checking for tmpnam > -configure:21210: > /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/xgcc > -shared-libgcc > -B/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc -nostdinc++ > -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux- > gnu/32/libstdc++-v3/src > -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux- > gnu/32/libstdc++-v3/src/.libs > -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux- > gnu/32/libstdc++-v3/libsupc++/.libs -B/usr/x86_64-pc-linux-gnu/bin/ > -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include > -isystem /usr/x86_64-pc-linux-gnu/sys-include -fno-checking -m32 -o > conftest -g -march=native -pipe -O2 -D_GNU_SOURCE -fno-exceptions > conftest.cpp >&5 > -/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/temp/cc2GI8iw.o:conftest.cpp: > function main: warning: the use of `tmpnam' is dangerous, better use > `mkstemp' > -configure:21210: $? = 0 > -configure:21226: result: yes > +configure:21210: > /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/xgcc > -shared-libgcc > -B/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc -nostdinc++ > -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux- > gnu/32/libstdc++-v3/src > -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux- > gnu/32/libstdc++-v3/src/.libs > -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux- > gnu/32/libstdc++-v3/libsupc++/.libs -B/usr/x86_64-pc-linux-gnu/bin/ > -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include > -isystem /usr/x86_64-pc-linux-gnu/sys-include -fchecking=1 -m32 -o conftest > -g -march=native -pipe -O2 -D_GNU_SOURCE -fno-exceptions conftest.cpp >&5 > +collect2: fatal error: ld terminated with signal 11 [Segmentation fault], > core dumped > +compilation terminated. > +configure:21210: $? = 1 Great find! Looks like it's an `ld` crash (`ld.gold` perhaps?). If it's non-deterministic that would explain why detection of `tmpnam` (and who knows what else) flaps back and forth from stage to stage. I suggest the following plan: 1. Verify that you can reproduce the crash by running above compiler command against source in config.log: """ configure: failed program was: | /* confdefs.h */ ... | } configure:21226: result: no """ 2. If it crashes check how deterministic it is: say, run link test 10 times and see if it will crash all 10 times or not. 3. get a symbolized backtrace from crashing ld > This is the difference between the compiler arguments: > @@ -11,7 +11,7 @@ > /usr/x86_64-pc-linux-gnu/include > -isystem > /usr/x86_64-pc-linux-gnu/sys-include > --fno-checking > +-fchecking=1 > > I'll attach both config.logs. -fno-checking / -fchecking=1 ideally should not change code generation (and input to `ld` should be the same for both options). I see a related failure when try to use gold: $ cat a.p.c void tmpnam(void); void _start(void) { tmpnam( # 1 "" ); } $ /usr/bin/x86_64-pc-linux-gnu-gcc-11.1.0 -c -o a.o -m32 -g a.p.c $ /usr/bin/x86_64-pc-linux-gnu-gcc-11.1.0 -o a -m32 -g a.o -fuse-ld=gold -nostdlib -lc /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.gold: internal error in format_file_lineno, at ../../binutils-2.36.1/gold/dwarf_reader.cc:2278 Which is no a SIGSEGV, but probably a very close relative. binutils-2.36.1's gold does not support dwarf-5 (gcc-11's default). That was fixed only in git master: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5cde809b7b9da3ad3aa0d65f0e5e92ab199d64f0 (In reply to Sergei Trofimovich from comment #21) > Great find! Looks like it's an `ld` crash (`ld.gold` perhaps?). If it's > non-deterministic that would explain why detection of `tmpnam` (and who > knows what else) flaps back and forth from stage to stage. I think it only flaps between stage 2 and 3 32 bit build. I have check other config.log file for tmpnam: /var/tmp/portage/sys-devel/gcc-11.1.0/work/build/stage2-x86_64-pc-linux-gnu/libstdc++-v3/config.log, /var/tmp/portage/sys-devel/gcc-11.1.0/work/build/stage3-x86_64-pc-linux-gnu/libstdc++-v3/config.log /usr/x86_64-pc-linux-gnu/bin/ld: internal error in format_file_lineno, at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/dwarf_reader.cc:2278 collect2: error: ld returned 1 exit status /var/tmp/portage/sys-devel/gcc-11.1.0/work/build/stage2-x86_64-pc-linux-gnu/32/libstdc++-v3/config.log function main: warning: the use of `tmpnam' is dangerous, better use `mkstemp' /var/tmp/portage/sys-devel/gcc-11.1.0/work/build/stage3-x86_64-pc-linux-gnu/32/libstdc++-v3/config.log: collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped /var/tmp/portage/sys-devel/gcc-11.1.0/work/build/build-x86_64-pc-linux-gnu/libiberty/config.log,/var/tmp/portage/sys-devel/gcc-11.1.0/work/build/stage3-libiberty/config.log, /var/tmp/portage/sys-devel/gcc-11.1.0/work/build/stage2-libiberty/config.log function main: warning: the use of `tmpnam' is dangerous, better use `mkstemp' > I suggest the following plan: > 1. Verify that you can reproduce the crash by running above compiler command > against source in config.log: > > """ > configure: failed program was: > | /* confdefs.h */ > ... > | } > configure:21226: result: no > """ > 2. If it crashes check how deterministic it is: say, run link test 10 times > and see if it will crash all 10 times or not. > 3. get a symbolized backtrace from crashing ld I'm not able to reproduce the segfault. I'm only getting the error from ld.gold about dwarf_reader. I have seen that coredumpctl lists the segfault from ld, so I have remerged binutils with: CFLAGS="${CFLAGS} -ggdb" CXXFLAGS="${CXXFLAGS} -ggdb" FEATURES="${FEATURES} splitdebug compressdebug" and now I'm recompiling GCC in the hope of getting a BT via coredumpctl. The segfault now occurs at other checks but the stage comparison was now successful. I will now remerge binutils without the debugging flags and check what happens if i compile gcc again. I also have now some backtraces of the crashed ld, they look similar but I can#t see what the excat reason for the segfault was, perhaps you can do siomething with the information, here is one example: wohnzimmernuc /tmp/gcc11 # coredumpctl debug 2269313 PID: 2269313 (ld) UID: 250 (portage) GID: 250 (portage) Signal: 11 (SEGV) Timestamp: Mon 2021-05-10 22:32:31 CEST (1min 23s ago) Command Line: /usr/x86_64-pc-linux-gnu/bin/ld -plugin /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/liblto_plugin.so -plugin-opt=/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/lto-wrapper -plugin-opt=-fresolution=/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/temp/ccajas8M.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -pie -o conftest /usr/lib/../lib/Scrt1.o /usr/lib/../lib/crti.o /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/32/crtbeginS.o -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/32 -L/lib/../lib -L/usr/lib/../lib -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc -L/usr/x86_64-pc-linux-gnu/bin -L/usr/x86_64-pc-linux-gnu/lib /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/temp/ccVByt4s.o -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/32/crtendS.o /usr/lib/../lib/crtn.o Executable: /usr/x86_64-pc-linux-gnu/binutils-bin/2.36.1/ld Control Group: /user.slice/user-0.slice/session-6.scope Unit: session-6.scope Slice: user-0.slice Session: 6 Owner UID: 0 (root) Boot ID: 4de733a066a8456a97ea4e90f741b452 Machine ID: d23c7a12b76315b709c9dae05fac8796 Hostname: localhost Storage: /var/lib/systemd/coredump/core.ld.250.4de733a066a8456a97ea4e90f741b452.2269313.1620678751000000.zst (present) Disk Size: 334.0K Message: Process 2269313 (ld) of user 250 dumped core. GNU gdb (Gentoo 10.2 vanilla) 10.2 Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/x86_64-pc-linux-gnu/binutils-bin/2.36.1/ld... Reading symbols from /usr/lib/debug//usr/x86_64-pc-linux-gnu/binutils-bin/2.36.1/ld.gold.debug... warning: Can't open file /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux-gnu/32/libgfortran/conftest during file-backed mapping note processing warning: Can't open file /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/temp/ccVByt4s.o during file-backed mapping note processing [New LWP 319911] Warning: couldn't activate thread debugging using libthread_db: Cannot find new threads: generic error warning: File "/lib64/libthread_db-1.0.so" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path /lib64/libthread_db-1.0.so line to your configuration file "/root/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/root/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/usr/x86_64-pc-linux-gnu/bin/ld -plugin /home/gentoo/tmp/portage/sys-devel/gcc-'. bProgram terminated with signal SIGSEGV, Segmentation fault. #0 0x000056422bcca71b in gold::Sized_dwarf_line_info<32, false>::process_one_opcode (this=this@entry=0x7ffc32b79af0, start=start@entry=0x81d908c9b510 <error: Cannot access memory at address 0x81d908c9b510>, lsm=lsm@entry=0x7ffc32b799b0, len=len@entry=0x7ffc32b79988) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/dwarf_reader.cc:1787 1787 /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/dwarf_reader.cc: Datei oder Verzeichnis nicht gefunden. (gdb) bt #0 0x000056422bcca71b in gold::Sized_dwarf_line_info<32, false>::process_one_opcode (this=this@entry=0x7ffc32b79af0, start=start@entry=0x81d908c9b510 <error: Cannot access memory at address 0x81d908c9b510>, lsm=lsm@entry=0x7ffc32b799b0, len=len@entry=0x7ffc32b79988) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/dwarf_reader.cc:1787 #1 0x000056422bccb696 in gold::Sized_dwarf_line_info<32, false>::read_lines (this=this@entry=0x7ffc32b79af0, lineptr=0x81d908c9b510 <error: Cannot access memory at address 0x81d908c9b510>, shndx=shndx@entry=4294967295) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/dwarf_reader.cc:1994 #2 0x000056422bccdbe0 in gold::Sized_dwarf_line_info<32, false>::read_line_mappings (this=this@entry=0x7ffc32b79af0, shndx=shndx@entry=4294967295) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/dwarf_reader.cc:2061 #3 0x000056422bcce01b in gold::Sized_dwarf_line_info<32, false>::Sized_dwarf_line_info (this=this@entry=0x7ffc32b79af0, object=0x56422de18490, read_shndx=read_shndx@entry=4294967295) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/dwarf_reader.cc:1630 #4 0x000056422bc1ec73 in gold::Relocate_info<32, false>::location[abi:cxx11](unsigned long, long) const (this=this@entry=0x7ffc32b79f90, offset=offset@entry=23) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/object.cc:3342 #5 0x000056422bbc144f in gold::gold_undefined_symbol_at_location<32, false> (sym=sym@entry=0x56422de3b9d0, relinfo=relinfo@entry=0x7ffc32b79f90, relnum=relnum@entry=2, reloffset=reloffset@entry=23) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/errors.cc:324 #6 0x000056422b9db595 in gold::relocate_section<32, false, (anonymous namespace)::Target_i386, (anonymous namespace)::Target_i386::Relocate, gold::Default_comdat_behavior, (anonymous namespace)::Target_i386::Classify_reloc> (reloc_symbol_changes=0x0, view_size=<optimized out>, view_address=960, view=0x7f93d87a33c0 "", needs_special_offset_handling=false, output_section=0x56422dde7490, reloc_count=3, prelocs=0x7f93d9d1e614 "", target=0x56422dde6d10, relinfo=0x7ffc32b79f90) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/target-reloc.h:462 #7 (anonymous namespace)::Target_i386::relocate_section (this=0x56422dde6d10, relinfo=0x7ffc32b79f90, sh_type=<optimized out>, prelocs=<optimized out>, reloc_count=3, output_section=0x56422dde7490, needs_special_offset_handling=false, view=0x7f93d87a33c0 "", address=960, view_size=<optimized out>, reloc_symbol_changes=0x0) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/i386.cc:3686 #8 0x000056422bc79688 in gold::Sized_relobj_file<32, false>::relocate_section_range (this=0x56422de18490, symtab=0x7ffc32b7a630, layout=<optimized out>, pshdrs=0x7f93d9d1e7c8 "", of=0x56422df094e0, pviews=0x7ffc32b7a060, start_shndx=1, end_shndx=26) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/reloc.cc:1005 #9 0x000056422bc79b11 in gold::Sized_relobj_file<32, false>::do_relocate_sections (this=<optimized out>, symtab=<optimized out>, layout=<optimized out>, pshdrs=<optimized out>, of=<optimized out>, pviews=<optimized out>) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/reloc.cc:874 #10 0x000056422bc75cb3 in gold::Sized_relobj_file<32, false>::relocate_sections (pviews=0x7ffc32b7a060, of=0x56422df094e0, pshdrs=0x7f93d9d1e7c8 "", layout=0x7ffc32b7a8f0, symtab=0x7ffc32b7a630, this=0x56422de18490) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/object.h:2728 #11 gold::Sized_relobj_file<32, false>::do_relocate (this=0x56422de18490, symtab=0x7ffc32b7a630, layout=0x7ffc32b7a8f0, of=0x56422df094e0) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/reloc.cc:631 #12 0x000056422bc6c19d in gold::Relobj::relocate (of=<optimized out>, layout=<optimized out>, symtab=<optimized out>, this=<optimized out>) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/object.h:1326 #13 gold::Relocate_task::run (this=0x56422df09780) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/reloc.cc:239 #14 0x000056422bcb7b68 in gold::Workqueue::find_and_run_task (this=0x7ffc32b7a330, thread_number=0) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/workqueue.cc:319 #15 0x000056422bcb7e0a in gold::Workqueue::process (this=this@entry=0x7ffc32b7a330, thread_number=thread_number@entry=0) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/workqueue.cc:495 #16 0x000056422b9c2750 in main (argc=<optimized out>, argv=<optimized out>) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/main.cc:252 (gdb) q (In reply to Steffen Hau from comment #24) > The segfault now occurs at other checks but the stage comparison was now > successful. I will now remerge binutils without the debugging flags and > check what happens if i compile gcc again. > > I also have now some backtraces of the crashed ld, they look similar but I > can#t see what the excat reason for the segfault was, perhaps you can do > siomething with the information, here is one example: > > wohnzimmernuc /tmp/gcc11 # coredumpctl debug 2269313 > PID: 2269313 (ld) > UID: 250 (portage) > GID: 250 (portage) > Signal: 11 (SEGV) > Timestamp: Mon 2021-05-10 22:32:31 CEST (1min 23s ago) > Command Line: /usr/x86_64-pc-linux-gnu/bin/ld -plugin > /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/liblto_plugin. > so > -plugin-opt=/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/ > lto-wrapper > -plugin-opt=-fresolution=/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/temp/ > ccajas8M.res -plugin-opt=-pass-through=-lgcc > -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc > -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s > --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -pie -o > conftest /usr/lib/../lib/Scrt1.o /usr/lib/../lib/crti.o > /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/32/crtbeginS. > o -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/32 > -L/lib/../lib -L/usr/lib/../lib > -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc > -L/usr/x86_64-pc-linux-gnu/bin -L/usr/x86_64-pc-linux-gnu/lib > /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/temp/ccVByt4s.o -lgcc > --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state > --as-needed -lgcc_s --pop-state > /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/32/crtendS.o > /usr/lib/../lib/crtn.o > Executable: /usr/x86_64-pc-linux-gnu/binutils-bin/2.36.1/ld > Control Group: /user.slice/user-0.slice/session-6.scope > Unit: session-6.scope > Slice: user-0.slice > Session: 6 > Owner UID: 0 (root) > Boot ID: 4de733a066a8456a97ea4e90f741b452 > Machine ID: d23c7a12b76315b709c9dae05fac8796 > Hostname: localhost > Storage: > /var/lib/systemd/coredump/core.ld.250.4de733a066a8456a97ea4e90f741b452. > 2269313.1620678751000000.zst (present) > Disk Size: 334.0K > Message: Process 2269313 (ld) of user 250 dumped core. > > GNU gdb (Gentoo 10.2 vanilla) 10.2 > Copyright (C) 2021 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "x86_64-pc-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <https://bugs.gentoo.org/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from /usr/x86_64-pc-linux-gnu/binutils-bin/2.36.1/ld... > Reading symbols from > /usr/lib/debug//usr/x86_64-pc-linux-gnu/binutils-bin/2.36.1/ld.gold.debug... > > warning: Can't open file > /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux-gnu/ > 32/libgfortran/conftest during file-backed mapping note processing > > warning: Can't open file > /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/temp/ccVByt4s.o during > file-backed mapping note processing > [New LWP 319911] > Warning: couldn't activate thread debugging using libthread_db: Cannot find > new threads: generic error > > warning: File "/lib64/libthread_db-1.0.so" auto-loading has been declined by > your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". > To enable execution of this file add > add-auto-load-safe-path /lib64/libthread_db-1.0.so > line to your configuration file "/root/.gdbinit". > To completely disable this security protection add > set auto-load safe-path / > line to your configuration file "/root/.gdbinit". > For more information about this security protection see the > "Auto-loading safe path" section in the GDB manual. E.g., run from the > shell: > info "(gdb)Auto-loading safe path" > > warning: Unable to find libthread_db matching inferior's thread library, > thread debugging will not be available. > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > Core was generated by `/usr/x86_64-pc-linux-gnu/bin/ld -plugin > /home/gentoo/tmp/portage/sys-devel/gcc-'. > bProgram terminated with signal SIGSEGV, Segmentation fault. > #0 0x000056422bcca71b in gold::Sized_dwarf_line_info<32, > false>::process_one_opcode (this=this@entry=0x7ffc32b79af0, > start=start@entry=0x81d908c9b510 <error: Cannot access memory at address > 0x81d908c9b510>, lsm=lsm@entry=0x7ffc32b799b0, len=len@entry=0x7ffc32b79988) > at > /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/ > gold/dwarf_reader.cc:1787 > 1787 > /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/ > gold/dwarf_reader.cc: Datei oder Verzeichnis nicht gefunden. > (gdb) bt > #0 0x000056422bcca71b in gold::Sized_dwarf_line_info<32, > false>::process_one_opcode (this=this@entry=0x7ffc32b79af0, > start=start@entry=0x81d908c9b510 <error: Cannot access memory at address > 0x81d908c9b510>, lsm=lsm@entry=0x7ffc32b799b0, len=len@entry=0x7ffc32b79988) > at > /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/ > gold/dwarf_reader.cc:1787 > #1 0x000056422bccb696 in gold::Sized_dwarf_line_info<32, false>::read_lines > (this=this@entry=0x7ffc32b79af0, lineptr=0x81d908c9b510 <error: Cannot > access memory at address 0x81d908c9b510>, shndx=shndx@entry=4294967295) > at > /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/ > gold/dwarf_reader.cc:1994 > #2 0x000056422bccdbe0 in gold::Sized_dwarf_line_info<32, Aha, the crash also stems from the inability to parse dwarf-5. I guess crash is very dependent in exact input and sometimes happens to work (as opposed to always crash). That makes Gentoo's gold incomatible with gcc-11. We will need a new gold. As a workaround you might need to switch to ld.bfd, or to gcc-10 or to CFLAGS/CXXFLAGS/LDFLAGS=-gdwarf-4. (In reply to Sergei Trofimovich from comment #25) > Aha, the crash also stems from the inability to parse dwarf-5. I guess crash > is very dependent in exact input and sometimes happens to work (as opposed > to always crash). > > That makes Gentoo's gold incomatible with gcc-11. We will need a new gold. > As a workaround you might need to switch to ld.bfd, or to gcc-10 or to > CFLAGS/CXXFLAGS/LDFLAGS=-gdwarf-4. Would it be possible to backport the patch you mentioned in comment 22 to binutils-2.36.1? (In reply to Steffen Hau from comment #26) > Would it be possible to backport the patch you mentioned in comment 22 to > binutils-2.36.1? I would prefer not to. There are a few patches and they are quite big. (In reply to Sergei Trofimovich from comment #27) > (In reply to Steffen Hau from comment #26) > > Would it be possible to backport the patch you mentioned in comment 22 to > > binutils-2.36.1? > > I would prefer not to. There are a few patches and they are quite big. so the to be released binutils-2.37.x would be the one with the fixes included? That's perhaps a question that upstream will be best to answer. seems as if sys-devel/binutils-2.37 has the patch included (In reply to tt_1 from comment #30) > seems as if sys-devel/binutils-2.37 has the patch included yes, and most dwarf5 support should also be in 2.36.1-r2 via the binutils stable branch. These older versions are masked. |