On 9/16/20 11:52 AM, Joseph Myers wrote:
> On Wed, 16 Sep 2020, Jeff Law via Gcc-patches wrote:
>
>> ISTM this is a lot like the problem we have where we inline functions
>> with static data.   To fix those we use STB_GNU_UNIQUE.  But I don't see
>> any code in the C front-end which would utilize STB_GNU_UNIQUE.  It's
>> support seems limited to C++.
>>
>>
>> How is this supposed to work for C?
> C inline functions don't try to address this.  The standard has a rule "An 
> inline definition of a function with external linkage shall not contain a 
> definition of a modifiable object with static or thread storage duration, 
> and shall not contain a reference to an identifier with internal 
> linkage.", which avoids some cases of this, but you can still get multiple 
> copies of objects (with static storage duration, not modifiable, no 
> linkage, i.e. static const defined inside an inline function) as noted in 
> a footnote "Since an inline definition is distinct from the corresponding 
> external definition and from any other corresponding inline definitions in 
> other translation units, all corresponding objects with static storage 
> duration are also distinct in each of the definitions.".

I was kindof guessing C would end up with something like the above --
I'm just happy its as well documented as it is.  Thanks!



The more I ponder this problem the more worried I get.   Before LTO we
could consider the TU an indivisible unit and if the main program
referenced something in the TU, then a static link of that TU would
bring the entire TU into the main program and that would satisfy all
references to all symbols defined by the TU, including those in any DSOs
used by the main program.  So it's an indivisible unit at runtime too. 
I could change internal data structures, rebuild the static library &
main program (leaving the DSOs alone) and it'd just work.


In an LTO world the TU isn't indivisible anymore.  LTO will happily
discard things which don't appear to be used.   So parts of the TU may
be in the main program, other parts may be in DSOs used by the main
program.   This can mean that objects are unexpectedly being passed
across DSO boundaries and the details of those objects has, in effect,
become part of the ABI.  If I was to change an internal data structure,
build the static library and main program we could get bad behavior
because an instance of that data structure could be passed to a DSO
because the main executable is "incomplete" and we end up calling copies
of routines from the (not rebuilt) DSOs.


Jeff