[Bug ld/26407] Global symbol reference breaks without -Bsymbolic-functions
https://sourceware.org/bugzilla/show_bug.cgi?id=26407 H.J. Lu changed: What|Removed |Added CC||binutils-972305 at jspam dot de --- Comment #10 from H.J. Lu --- *** Bug 26928 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26407] Global symbol reference breaks without -Bsymbolic-functions
https://sourceware.org/bugzilla/show_bug.cgi?id=26407 --- Comment #9 from H.J. Lu --- (In reply to Michael Matz from comment #8) > I wonder if we shouldn't mark symbols that are internalized but referenced > (and hence have relocs to them removed) and still exported such that when a > binary is created that contains a copy relocation to them could at least be > warned about > when creating such binary. There are a couple bits available in the symbol > table > entries. Also see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26407] Global symbol reference breaks without -Bsymbolic-functions
https://sourceware.org/bugzilla/show_bug.cgi?id=26407 Michael Matz changed: What|Removed |Added CC||matz at suse dot de --- Comment #8 from Michael Matz --- I wonder if we shouldn't mark symbols that are internalized but referenced (and hence have relocs to them removed) and still exported such that when a binary is created that contains a copy relocation to them could at least be warned about when creating such binary. There are a couple bits available in the symbol table entries. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26407] Global symbol reference breaks without -Bsymbolic-functions
https://sourceware.org/bugzilla/show_bug.cgi?id=26407 H.J. Lu changed: What|Removed |Added Resolution|--- |WONTFIX Status|WAITING |RESOLVED --- Comment #7 from H.J. Lu --- (In reply to Fabian Vogt from comment #6) > (In reply to H.J. Lu from comment #4) > > '--dynamic-list=DYNAMIC-LIST-FILE' > > Specify the name of a dynamic list file to the linker. This is > > typically used when creating shared libraries to specify a list of > > global symbols whose references shouldn't be bound to the > > definition within the shared library, or creating dynamically > > linked executables to specify a list of symbols which should be > > added to the symbol table in the executable. This option is only > > meaningful on ELF platforms which support shared libraries. > > > > So symbols aren't on the dynamic list will be bound to the definition > > within the shared library. The linker behavior matches the linker > > manual. > > That doesn't explain the behaviour change with -Bsymbolic-functions and the > different behaviour with gold. Let focus on ld. -Bsymbolic-functions changes behavior is a bug, which has been fixed in 2.35. > The definition of the symbol is inside lib.so, so there is no reason this > shouldn't work. ? > This breaks because the break binary has a R_X86_64_COPY relocation, which > essentially moves the symbol out of the lib into the executable. > > IMO copy relocations are an implementation detail which should be made as > compatible as possible, in this case maybe by making --dynamic-list-data the > default if --dynamic-list is passed. There is no different between value and setValue as far as --dynamic-list is concerned. Linker provides precise controls with command-line options. You need to tell linker exactly what you need. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26407] Global symbol reference breaks without -Bsymbolic-functions
https://sourceware.org/bugzilla/show_bug.cgi?id=26407 --- Comment #6 from Fabian Vogt --- (In reply to H.J. Lu from comment #4) > '--dynamic-list=DYNAMIC-LIST-FILE' > Specify the name of a dynamic list file to the linker. This is > typically used when creating shared libraries to specify a list of > global symbols whose references shouldn't be bound to the > definition within the shared library, or creating dynamically > linked executables to specify a list of symbols which should be > added to the symbol table in the executable. This option is only > meaningful on ELF platforms which support shared libraries. > > So symbols aren't on the dynamic list will be bound to the definition > within the shared library. The linker behavior matches the linker > manual. That doesn't explain the behaviour change with -Bsymbolic-functions and the different behaviour with gold. The definition of the symbol is inside lib.so, so there is no reason this shouldn't work. This breaks because the break binary has a R_X86_64_COPY relocation, which essentially moves the symbol out of the lib into the executable. IMO copy relocations are an implementation detail which should be made as compatible as possible, in this case maybe by making --dynamic-list-data the default if --dynamic-list is passed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26407] Global symbol reference breaks without -Bsymbolic-functions
https://sourceware.org/bugzilla/show_bug.cgi?id=26407 --- Comment #5 from H.J. Lu --- It sounds like you need '--dynamic-list-data' Include all global data symbols to the dynamic list. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26407] Global symbol reference breaks without -Bsymbolic-functions
https://sourceware.org/bugzilla/show_bug.cgi?id=26407 --- Comment #4 from H.J. Lu --- '--dynamic-list=DYNAMIC-LIST-FILE' Specify the name of a dynamic list file to the linker. This is typically used when creating shared libraries to specify a list of global symbols whose references shouldn't be bound to the definition within the shared library, or creating dynamically linked executables to specify a list of symbols which should be added to the symbol table in the executable. This option is only meaningful on ELF platforms which support shared libraries. So symbols aren't on the dynamic list will be bound to the definition within the shared library. The linker behavior matches the linker manual. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26407] Global symbol reference breaks without -Bsymbolic-functions
https://sourceware.org/bugzilla/show_bug.cgi?id=26407 Martin Liska changed: What|Removed |Added CC||mliska at suse dot cz --- Comment #3 from Martin Liska --- (In reply to H.J. Lu from comment #1) > Please make it a run-time test. It is a run-time test-case. He executes binary called 'break'. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26407] Global symbol reference breaks without -Bsymbolic-functions
https://sourceware.org/bugzilla/show_bug.cgi?id=26407 --- Comment #2 from Fabian Vogt --- (In reply to H.J. Lu from comment #1) > Please make it a run-time test. Sorry, I don't understand what you mean by that. The break executable only returns 42 with the working lib.so, it doesn't have to be recompiled. FTR, this issue does not happen with gold: # gcc -fuse-ld=gold -fPIC -shared -Wl,--dynamic-list,lib.dynlist -o lib.so lib.i && readelf --dyn-syms -r lib.so | grep value 1fe0 00080006 R_X86_64_GLOB_DAT 2014 value + 0 8: 2014 4 OBJECT GLOBAL DEFAULT 24 value # LD_LIBRARY_PATH=$PWD ./break; echo $? 42 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26407] Global symbol reference breaks without -Bsymbolic-functions
https://sourceware.org/bugzilla/show_bug.cgi?id=26407 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-08-19 CC||hjl.tools at gmail dot com Status|UNCONFIRMED |WAITING --- Comment #1 from H.J. Lu --- Please make it a run-time test. -- You are receiving this mail because: You are on the CC list for the bug.
