[Bug binutils/29785] memory bloat in version 2.39
https://sourceware.org/bugzilla/show_bug.cgi?id=29785 Joel Hock changed: What|Removed |Added CC||joelhock at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30930] ld-2.41 links mame in a way which gets stuck on aarch64
https://sourceware.org/bugzilla/show_bug.cgi?id=30930 --- Comment #17 from Julian Sikorski --- (In reply to Nick Clifton from comment #16) > Created attachment 15152 [details] > Proposed patch > > (In reply to Julian Sikorski from comment #13) > > Thanks! The patch does not revert cleanly unfortunately and the changes are > > complicated enough that I do not feel comfortable running git mergetool. > > Would someone please be so kind and provide a patch I can apply against > > 2.41? > > Please try this patch. Thanks! With this patch applied the linked mame binary no longer gets stuck. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30930] ld-2.41 links mame in a way which gets stuck on aarch64
https://sourceware.org/bugzilla/show_bug.cgi?id=30930 --- Comment #16 from Nick Clifton --- Created attachment 15152 --> https://sourceware.org/bugzilla/attachment.cgi?id=15152&action=edit Proposed patch (In reply to Julian Sikorski from comment #13) > Thanks! The patch does not revert cleanly unfortunately and the changes are > complicated enough that I do not feel comfortable running git mergetool. > Would someone please be so kind and provide a patch I can apply against 2.41? Please try this patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30930] ld-2.41 links mame in a way which gets stuck on aarch64
https://sourceware.org/bugzilla/show_bug.cgi?id=30930 Sam James changed: What|Removed |Added CC||nsz at gcc dot gnu.org --- Comment #15 from Sam James --- ./configure --disable-werror -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30792] Rnglists section dump in readelf outputs one rangelist per CU
https://sourceware.org/bugzilla/show_bug.cgi?id=30792 Nick Clifton changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Nick Clifton --- Patch applied. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #25 from Nick Clifton --- (In reply to Vsevolod Alekseyev from comment #24) > On a side note - this one is marked as fixed, and 30792 is not, is that > right? Doh - sorry - forgot to close 30792. Doing it now... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30930] ld-2.41 links mame in a way which gets stuck on aarch64
https://sourceware.org/bugzilla/show_bug.cgi?id=30930 --- Comment #14 from Julian Sikorski --- (In reply to Julian Sikorski from comment #10) > Done: https://bugzilla.redhat.com/show_bug.cgi?id=2241902 > > I managed to set up an aarch64 rawhide instance on Oracle Cloud but I cannot > connect to it yet :( If I manage to get it working, I can see if I can set > up a bisect mentioned in comment #2. Is there a straightforward way of disabling -Werror for non-releases? I got my cloud instance running but I cannot build a mid-release snapshot due to this. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30930] ld-2.41 links mame in a way which gets stuck on aarch64
https://sourceware.org/bugzilla/show_bug.cgi?id=30930 --- Comment #13 from Julian Sikorski --- Thanks! The patch does not revert cleanly unfortunately and the changes are complicated enough that I do not feel comfortable running git mergetool. Would someone please be so kind and provide a patch I can apply against 2.41? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #24 from Vsevolod Alekseyev --- Thanks. I'll take a look at 30880 next. On a side note - this one is marked as fixed, and 30792 is not, is that right? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30930] ld-2.41 links mame in a way which gets stuck on aarch64
https://sourceware.org/bugzilla/show_bug.cgi?id=30930 Carlos O'Donell changed: What|Removed |Added CC||carlos at redhat dot com --- Comment #12 from Carlos O'Donell --- I suggest starting by reverting the BTI stub change: commit 15b4f66b0a9a3be6caf1898d22a13c39e662006f Author: Szabolcs Nagy Date: Wed Jan 18 12:56:46 2023 + bfd: aarch64: Fix stubs that may break BTI PR30076 Insert two stubs in a BTI enabled binary when fixing long calls: The first is near the call site and uses an indirect jump like before, but it targets the second stub that is near the call target site and uses a direct jump. This is needed when a single stub breaks BTI compatibility. The stub layout is kept fixed between sizing and building the stubs, so the location of the second stub is known at build time, this may introduce padding between stubs when those are relaxed. Stub layout with BTI disabled is unchanged. ... and see if that fixes the issue. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30930] ld-2.41 links mame in a way which gets stuck on aarch64
https://sourceware.org/bugzilla/show_bug.cgi?id=30930 --- Comment #11 from Julian Sikorski --- With a non-mock, fedpkg compile build on Fedora rawhide aarch running on OCI the backtrace is slightly different: #0 0xb5bd4fb0 in ___ZN3emu6detail16device_registrar15register_deviceERNS0_21device_type_impl_baseE_bti_veneer () #1 0xaec52368 in device_type_impl_base () at ../../../../../src/emu/device.h:240 #2 device_type_impl () at ../../../../../src/emu/device.h:283 #3 __static_initialization_and_destruction_0 () at ../../../../../src/mame/acorn/z88_impexp.cpp:34 #4 _GLOBAL__sub_I_Z88_IMPEXP () at ../../../../../src/mame/acorn/z88_impexp.cpp:278 #5 0xf5870b2c in call_init (env=, argv=0xf258, argc=2) at ../csu/libc-start.c:145 #6 __libc_start_main_impl (main=0xaeedadc0 , argc=2, argv=0xf258, init=, fini=, rtld_fini=, stack_end=) at ../csu/libc-start.c:347 #7 0xaef01570 in _start -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30930] ld-2.41 links mame in a way which gets stuck on aarch64
https://sourceware.org/bugzilla/show_bug.cgi?id=30930 --- Comment #10 from Julian Sikorski --- Done: https://bugzilla.redhat.com/show_bug.cgi?id=2241902 I managed to set up an aarch64 rawhide instance on Oracle Cloud but I cannot connect to it yet :( If I manage to get it working, I can see if I can set up a bisect mentioned in comment #2. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30930] ld-2.41 links mame in a way which gets stuck on aarch64
https://sourceware.org/bugzilla/show_bug.cgi?id=30930 --- Comment #9 from Nick Clifton --- (In reply to Julian Sikorski from comment #8) > How would I bring in help from glibc folks? Should I just reassign the bug > to glibc? Yes/No. Since you are using Fedora and there is a possibility that this problem is specific to that distribution, I think that the best thing to do would be to file a new ticket with the Fedora bug tracking system, assigned to glibc for now. They can always change it to being a binutils ticket once they can show what the linker is doing wrong. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30930] ld-2.41 links mame in a way which gets stuck on aarch64
https://sourceware.org/bugzilla/show_bug.cgi?id=30930 --- Comment #8 from Julian Sikorski --- (In reply to Nick Clifton from comment #7) > (In reply to Julian Sikorski from comment #5) > > (In reply to Nick Clifton from comment #4) > > > You may find it useful to compare a broken-linked-with-ld.bfd binary > > > with a working-linked-with-lld binary. In particular the contents > > > of whatever init sections they have, and the ordering of function > > > pointers therein. > > > > I am downloading the broken binary from the test system now. How can I do > > the above? > > Well first you can compare the disassembly of the .init section to make sure > that it is the same in both binaries: > > objdump -D -j .init mame > > Next I was going to suggest that you check the contents of the .init_array > section but it appears to be all zeros, which is a bit strange. > > You could be paranoid and check that the hardware property notes are the > same on both binaries: > > readelf -n -W mame | grep -e .note.gnu.property -A 4 > > But I doubt if that show any discrepancies. > > But I suspect that the only real way you are going to get some traction on > this problem is if you bring in the glibc folks. Maybe file a bug report > telling them that mame is hanging during initialization and that you need > their help finding out where things have gone wrong ? Let them know about > the new version of binutils of course, but do ask them if they can track > down exactly what the linker has done wrong in order to cause the init code > to hang. How would I bring in help from glibc folks? Should I just reassign the bug to glibc? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30930] ld-2.41 links mame in a way which gets stuck on aarch64
https://sourceware.org/bugzilla/show_bug.cgi?id=30930 --- Comment #7 from Nick Clifton --- (In reply to Julian Sikorski from comment #5) > (In reply to Nick Clifton from comment #4) > > You may find it useful to compare a broken-linked-with-ld.bfd binary > > with a working-linked-with-lld binary. In particular the contents > > of whatever init sections they have, and the ordering of function > > pointers therein. > > I am downloading the broken binary from the test system now. How can I do > the above? Well first you can compare the disassembly of the .init section to make sure that it is the same in both binaries: objdump -D -j .init mame Next I was going to suggest that you check the contents of the .init_array section but it appears to be all zeros, which is a bit strange. You could be paranoid and check that the hardware property notes are the same on both binaries: readelf -n -W mame | grep -e .note.gnu.property -A 4 But I doubt if that show any discrepancies. But I suspect that the only real way you are going to get some traction on this problem is if you bring in the glibc folks. Maybe file a bug report telling them that mame is hanging during initialization and that you need their help finding out where things have gone wrong ? Let them know about the new version of binutils of course, but do ask them if they can track down exactly what the linker has done wrong in order to cause the init code to hang. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #23 from Nick Clifton --- Thanks - patch applied. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #22 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8c7125feaaa495b2aa0fed6cd077e35d0d90df43 commit 8c7125feaaa495b2aa0fed6cd077e35d0d90df43 Author: Vsevolod Alekseyev Date: Tue Oct 3 09:27:27 2023 +0100 Fix: readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx PR 29267 * dwarf.c (fetch_indexed_value): Delete. (fetch_indexed_offset): Correct base address calculation. (read_and_display_attr_value): Replace uses of fetch_indexed_value with fetch_indexed_offset. -- You are receiving this mail because: You are on the CC list for the bug.
