[Bug gold/23411] Different behavior when linking common symbol statically or to shared object

[zenith432 at users dot sourceforge.net]

https://sourceware.org/bugzilla/show_bug.cgi?id=23411

zenith432 at users dot sourceforge.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zenith432 at users dot 
sourceforge
                   |                            |.net

--- Comment #6 from zenith432 at users dot sourceforge.net ---
(In reply to Alexander Monakov from comment #1)
> I think the behavior exhibited by gold is expected given absence of
> --whole-archive, and it's ld.bfd that is doing something not mandated by the
> ELF spec here.

So the ELF spec does lay down an undecisive law for dynamic linking of common. 
Couldn't find anything comparable for static linking of archives.

http://www.sco.com/developers/gabi/latest/ch4.symtab.html
section 4.20
When the dynamic linker encounters a reference to a symbol that resolves to a
definition of type STT_COMMON, it may (but is not required to) change its
symbol resolution rules as follows: instead of binding the reference to the
first symbol found with the given name, the dynamic linker searches for the
first symbol with that name with type other than STT_COMMON. If no such symbol
is found, it looks for the STT_COMMON definition of that name that has the
largest size.

In the prior section 4.19 there is something about weak symbols which have
similar search conundrums
     When the link editor combines several relocatable object files, it does
not allow multiple definitions of STB_GLOBAL symbols with the same name. On the
other hand, if a defined global symbol exists, the appearance of a weak symbol
with the same name will not cause an error. The link editor honors the global
definition and ignores the weak ones. Similarly, if a common symbol exists
(that is, a symbol whose st_shndx field holds SHN_COMMON), the appearance of a
weak symbol with the same name will not cause an error. The link editor honors
the common definition and ignores the weak ones.

    When the link editor searches archive libraries [see ``Archive File'' in
Chapter 7], it extracts archive members that contain definitions of undefined
global symbols. The member's definition may be either a global or a weak
symbol. The link editor does not extract archive members to resolve undefined
weak symbols. Unresolved weak symbols have a zero value.

============
The ambiguity I mentioned about ANSI C is resolved by noticing that Annex J.5
is a list of common externsions to C.  They are allowed by the STD for
portability, but not necessarily conforming.

The GCC documentation for -fno-common states
=====
fno-common
In C code, this option controls the placement of global variables defined with-
out an initializer, known as tentative definitions in the C standard. 
Tentative definitions are distinct from declarations of a variable with the
extern keyword, which do not allocate storage.
Unix C compilers have traditionally allocated storage for uninitialized global
variables  in  a  common  block.   This  allows  the  linker  to  resolve  all 
tentative definitions of the same variable in different compilation units to
the same object, or to a non-tentative definition.  This is the behavior
specified by ‘-fcommon’, and is the default for GCC on most targets.  On the
other hand, this behavior is not required by ISO C, and on some targets may
carry a speed or code size penalty on variable references.
The ‘-fno-common’ option specifies that the compiler should instead place
unini-
tialized global variables in the data section of the object file.  This
inhibits the merging of tentative definitions by the linker so you get a
multiple-definition error if the same variable is defined in more than one
compilation unit.  Compiling with ‘-fno-common’ is useful on targets for which
it provides better performance, or if you wish to verify that the program will
work on other systems that always treat uninitialized variable definitions this
way.
=====
So the GCC doc claims that the common-based implementation of tentative
definitions is simply "not required by ISO C", but the last sentence is a tacit
admission that it is in fact non-conforming to ISO C - non-portable.

-- 
You are receiving this mail because:
You are on the CC list for the bug.