[Bug ld/25236] common symbol: don't consider definitions in shared objects
https://sourceware.org/bugzilla/show_bug.cgi?id=25236 --- Comment #4 from Alan Modra --- No, I'm not saying a common in a shared library wins over a common in a regular object, just that the maximum size is taken into account. See the comment in bfd/elflink.c starting /* NEWDYNCOMMON and OLDDYNCOMMON indicate .. It's interesting that the comment mentions fortran too. I believe this is Ian's code from 1997 or so. See also https://www.airs.com/blog/archives/49 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25236] common symbol: don't consider definitions in shared objects
https://sourceware.org/bugzilla/show_bug.cgi?id=25236 --- Comment #3 from Fangrui Song --- Maybe we should discuss on the generic ABI mailing list. It is very late here (01:00) so I'll not do that now. If you create a thread, can you CC me? My feeling is that a STN_COMMON (STT_COMMON) definition in a shared object should be treated as a regular definition, not a common symbol. It is subject to copy relocations. Only STN_COMMON (STT_COMMON) from object files are assigned st_size comparing semantics. If we choose the interpretation that the common definition from a shared object wins, it will break the rule that object file definitions beat shared definitions. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25236] common symbol: don't consider definitions in shared objects
https://sourceware.org/bugzilla/show_bug.cgi?id=25236 Alan Modra changed: What|Removed |Added CC||iant at google dot com -- You are receiving this mail because: You are on the CC list for the bug.
Re: Bug Report ( sensitive information on Github )
kunal mhaske writes: > Because the github leak the your engineers id and password You seem to be confusing binut...@sourceware.org with a Red Hat mailing list. Ian > On Thu 5 Dec, 2019, 9:41 PM Ian Lance Taylor, wrote: > >> kunal mhaske writes: >> >> > Any update on this? >> >> I don't understand why you are reporting this to bug-binutils@gnu.org. >> >> Ian >>
Re: Bug Report ( sensitive information on Github )
Yes, I did. On Fri 6 Dec, 2019, 12:12 PM Ian Lance Taylor, wrote: > kunal mhaske writes: > > > Because the github leak the your engineers id and password > > You seem to be confusing binut...@sourceware.org with a Red Hat mailing > list. > > Ian > > > On Thu 5 Dec, 2019, 9:41 PM Ian Lance Taylor, wrote: > > > >> kunal mhaske writes: > >> > >> > Any update on this? > >> > >> I don't understand why you are reporting this to bug-binutils@gnu.org. > >> > >> Ian > >> >
[Bug ld/25236] common symbol: don't consider definitions in shared objects
https://sourceware.org/bugzilla/show_bug.cgi?id=25236 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com --- Comment #5 from Ian Lance Taylor --- As I recall the behavior in GNU ld is due to SunOS. On SunOS when a shared library defined a common symbol it was required for the main executable to define the symbol with the same size. I think the shared library would then refer to the executable's symbol, so if the size were not the same (or larger) the program would break. I think this approach was required for stdin/stdout/stderr, but I may be misremembering. If a common symbol in a shared library is going to be resolved to a common symbol in the main executable, then it seems essential to consider the size of the common symbol in the shared library. If the two symbols are going to be treated as distinct, then it doesn't matter. So I think the resolution here hinges on that question. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25236] common symbol: don't consider definitions in shared objects
https://sourceware.org/bugzilla/show_bug.cgi?id=25236 --- Comment #6 from Fangrui Song --- To make sure we are on the same page. In the case that both a.o and a.so define the common symbol: The definition from a.o wins. --version-script should apply versions on the definition. At runtime, the shared object should refer to the executable's symbol. (This is the regular rule for definitions.) st_size: largest st_size from all object files and shared objects alignment: largest st_value (alignment) from all object files and shared objects In my pasted example, mpi_fortran_argvs_null_ should have the default version OMPI_2.0.0 and st_size=8. Action items: gold/lld: respect st_size/st_value in shared objects ld: fix VER_NDX_LOCAL -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25236] common symbol: don't consider definitions in shared objects
https://sourceware.org/bugzilla/show_bug.cgi?id=25236 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-12-07 CC|amodra at gmail dot com| Assignee|unassigned at sourceware dot org |amodra at gmail dot com Ever confirmed|0 |1 --- Comment #7 from Alan Modra --- Agreed. I have a patch for the ld.bfd version problem. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25236] common symbol: don't consider definitions in shared objects
https://sourceware.org/bugzilla/show_bug.cgi?id=25236 --- Comment #8 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=5fa370e437f39bf73a133cc84c4e6329943522bf commit 5fa370e437f39bf73a133cc84c4e6329943522bf Author: Alan Modra Date: Fri Dec 6 11:21:45 2019 +1030 PR25236, common sym versioning In cases where a relocatable object file has a common symbol, no other file has a definition, and there is a matching common symbol found in a shared library then ld will output a definition using the largest of size and alignment for the commons. This patch fixes a bug in ld that ignored common symbols when assigning versions, resulting in such symbols being given VER_NDX_LOCAL versions. PR 25236 * elflink.c (_bfd_elf_link_assign_sym_version): Assign versions for ELF_COMMON_DEF_P symbols. (elf_link_output_extsym, _bfd_elf_add_default_symbol): Adjust to suit. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25236] common symbols ignore size and alignment of symbols in shared libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=25236 Alan Modra changed: What|Removed |Added Status|ASSIGNED|NEW CC||amodra at gmail dot com Component|ld |gold Assignee|amodra at gmail dot com|ccoutant at gmail dot com Summary|common symbol: don't|common symbols ignore size |consider definitions in |and alignment of symbols in |shared objects |shared libraries --- Comment #9 from Alan Modra --- Fixed for bfd linker. -- You are receiving this mail because: You are on the CC list for the bug.
