[Bug ld/29761] relocatable linking loses some symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29761 --- Comment #8 from Stas Sergeev --- Please run `nm a.out | grep 2000` after test.sh. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29761] relocatable linking loses some symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29761 --- Comment #7 from Stas Sergeev --- Created attachment 14465 --> https://sourceware.org/bugzilla/attachment.cgi?id=14465=edit new test-case Here is a new test-case that shows the symbol name drop even w/o relocatable linking. Please check on a new/patched binutils, as I suspect we need to re-open this. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29807] SIGSEGV when linking fuzzed PE object
https://sourceware.org/bugzilla/show_bug.cgi?id=29807 --- Comment #3 from Stas Sergeev --- Created attachment 14464 --> https://sourceware.org/bugzilla/attachment.cgi?id=14464=edit elf test-case Here is the original objects which I converted to PE. Without conversion to PE, the link succeeds, as can be seen by running test.sh from that archive. However! With nm you can see that one symbol have lost its name again, as was the case in a nearby report about relocatable linking. But this time the linking is not relocatable. So I suspect we need to re-open also that. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29807] SIGSEGV when linking fuzzed PE object
https://sourceware.org/bugzilla/show_bug.cgi?id=29807 --- Comment #2 from Alan Modra --- Hmm, OK. What triggered the problem is that you have relocations against a file symbol, which of course is more than a little weird. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29807] SIGSEGV when linking fuzzed PE object
https://sourceware.org/bugzilla/show_bug.cgi?id=29807 --- Comment #1 from Stas Sergeev --- JFYI, I have created that object with objcopy from elf. Not sure what is fuzzed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29807] SIGSEGV when linking fuzzed PE object
https://sourceware.org/bugzilla/show_bug.cgi?id=29807 Alan Modra changed: What|Removed |Added Ever confirmed|0 |1 Summary|SIGSEGV when linking PE |SIGSEGV when linking fuzzed ||PE object Assignee|unassigned at sourceware dot org |amodra at gmail dot com Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-11-18 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29802] Segmentation fault in _bfd_elf_strtab_add
https://sourceware.org/bugzilla/show_bug.cgi?id=29802 --- Comment #4 from John David Anglin --- Created attachment 14463 --> https://sourceware.org/bugzilla/attachment.cgi?id=14463=edit Patch For reference, I have this patch installed to fix a problem with OTHER_SYMBOLS. The symbols __SYSTEM_ID through __TLS_PREALLOC_DTV_A are undefined in crt0.o. HP ld provides these. The symbols __SYSTEM_ID_D through __systab are undefined in libc.sl. HP ld does not provide them. It ignores them. My understanding is they are likely set by the kernel. I provided them because GNU ld default behavior is to error on undefined shared library symbols. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29802] Segmentation fault in _bfd_elf_strtab_add
https://sourceware.org/bugzilla/show_bug.cgi?id=29802 --- Comment #3 from dave.anglin at bell dot net --- On 2022-11-18 4:30 p.m., dave.anglin at bell dot net wrote: > readelf: Warning: [ 4]: Link field (0) should index a symtab section. Sorry, cut this off: [ 3] .dynstr STRTAB 40001940 1940 0c41 A 0 0 1 readelf: Warning: [ 4]: Link field (0) should index a symtab section. [ 4] .hash HASH 40002588 2588 0740 A 0 0 8 0x0004 (HASH) 0x40002588 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29802] Segmentation fault in _bfd_elf_strtab_add
https://sourceware.org/bugzilla/show_bug.cgi?id=29802 --- Comment #2 from dave.anglin at bell dot net --- On 2022-11-18 3:51 p.m., amodra at gmail dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=29802 > > --- Comment #1 from Alan Modra --- > What sort of local symbol are you trying to make dynamic? A section symbol? I'd have to debug more to be certain but when I dump a shared library generated using HP ld I see the following messages: Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0 0 0 [ 1] .dynamic DYNAMIC 41c8 01c8 01a0 0010 A 3 0 8 [ 2] .dynsym DYNSYM 4368 0368 15d8 0018 A 3 0 8 [ 3] .dynstr STRTAB 40001940 1940 0c41 A 0 0 1 readelf: Warning: [ 4]: Link field (0) should index a symtab section. ... Symbol table '.dynsym' contains 233 entries: Num: Value Size Type Bind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND readelf: Warning: local symbol 0 found at index >= .dynsym's sh_info value of 0 1: 41c8 0 SECTION LOCAL DEFAULT 1 __text_seg readelf: Warning: local symbol 1 found at index >= .dynsym's sh_info value of 0 2: 8001 0 SECTION LOCAL DEFAULT 20 __data_seg readelf: Warning: local symbol 2 found at index >= .dynsym's sh_info value of 0 3: 80013238 0 SECTION LOCAL DEFAULT 39 __thread_specific_seg readelf: Warning: local symbol 3 found at index >= .dynsym's sh_info value of 0 4: 80011910 96 FUNC GLOBAL DEFAULT 19 __lshrti3 I see these in links as well. /opt/gnu64/bin/ld: warning: /lib/pa20_64/libc.sl has a section extending past end of file /opt/gnu64/bin/ld: /lib/pa20_64/libc.sl: .dynsym local symbol at index 0 (>= sh_info of 0) /opt/gnu64/bin/ld: /lib/pa20_64/libc.sl: .dynsym local symbol at index 1 (>= sh_info of 0) /opt/gnu64/bin/ld: /lib/pa20_64/libc.sl: .dynsym local symbol at index 2 (>= sh_info of 0) /opt/gnu64/bin/ld: /lib/pa20_64/libc.sl: .dynsym local symbol at index 3 (>= sh_info of 0) /opt/gnu64/bin/ld: /usr/lib/pa20_64/libdl.1: .dynsym local symbol at index 0 (>= sh_info of 0) /opt/gnu64/bin/ld: /usr/lib/pa20_64/libdl.1: .dynsym local symbol at index 1 (>= sh_info of 0) /opt/gnu64/bin/ld: /usr/lib/pa20_64/libdl.1: .dynsym local symbol at index 2 (>= sh_info of 0) /opt/gnu64/bin/ld: /usr/lib/pa20_64/libdl.1: .dynsym local symbol at index 3 (>= sh_info of 0) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29802] Segmentation fault in _bfd_elf_strtab_add
https://sourceware.org/bugzilla/show_bug.cgi?id=29802 --- Comment #1 from Alan Modra --- What sort of local symbol are you trying to make dynamic? A section symbol? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29807] New: SIGSEGV when linking PE
https://sourceware.org/bugzilla/show_bug.cgi?id=29807 Bug ID: 29807 Summary: SIGSEGV when linking PE Product: binutils Version: 2.39 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: stsp at users dot sourceforge.net Target Milestone: --- Created attachment 14462 --> https://sourceware.org/bugzilla/attachment.cgi?id=14462=edit test case Attached is a test-case. Shell script runs ld -mi386pe crt0.o libc.a and that sigsegves. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/22589] aarch64: adrp relocation gets filled with non-zero address for undefined weak symbol
https://sourceware.org/bugzilla/show_bug.cgi?id=22589 Szabolcs Nagy changed: What|Removed |Added CC||nsz at gcc dot gnu.org --- Comment #9 from Szabolcs Nagy --- i ran into this again and i think the linker could relax 'adrp xN, weaksym' into 'mov xN, 0' if weaksym is undefined. link error is not helpful since such code (accessing weak symbols) may be behind checks and unreachable if the symbol is undefined. normally weak syms are accessed via GOT which can be 0 for undef, but in PIC this depends on a dynamic relocation even for hidden visibility syms. this does not work in early start code (e.g. *crt1.o) accessing weak, linker generated symbols (such as __ehdr_start) where the code must not generate dynamic relocations (since it may be executed before ld.so or static pie self relocation). if such symbol is potentially undefined then we have a problem: adrp does not work, GOT does not work, movz does not work. so i dont see a way to implement if ( != 0) use(); logic in the ld.so or static pie start code. i ran into this with the morello port where there are linker created symbols (__rela_dyn_start) that are only defined under certain conditions (static exe with no dynamic-linker) and must be checked and accessed in gcrt1.o that is used in both pde and pie. -- You are receiving this mail because: You are on the CC list for the bug.
GNU Binutils Lands New "SFrame" Format Support For Simple Stack Unwinding
Subject: GNU Binutils Lands New "SFrame" Format Support For Simple Stack Unwinding Good day from Singapore, Sharing this news article regarding GNU Binutils. Article: GNU Binutils Lands New "SFrame" Format Support For Simple Stack Unwinding Link: https://www.phoronix.com/news/GNU-Binutils-SFrame Regards, Mr. Turritopsis Dohrnii Teo En Ming Targeted Individual in Singapore Blogs: https://tdtemcerts.blogspot.com https://tdtemcerts.wordpress.com
[Bug gold/23842] "dwp -e" doesn't consult DW_AT_comp_dir attributes
https://sourceware.org/bugzilla/show_bug.cgi?id=23842 Jordan Williams changed: What|Removed |Added CC||jordan at jwillikers dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29803] Relax failed between different output section
https://sourceware.org/bugzilla/show_bug.cgi?id=29803 --- Comment #4 from Alan Modra --- Yes, the first pass will be as you say, but with relax_again set you'll get another pass at relaxation. When the first pass is finished you should have a layout that reflects any changed section size. The second pass will then use that layout to possibly perform further relaxation. And so on. -- You are receiving this mail because: You are on the CC list for the bug.
