Problem with static const objects and LTO

[Jeff Law]

On 10/7/20 5:12 PM, H.J. Lu wrote:
> On Wed, Oct 7, 2020 at 3:09 PM Jeff Law via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>> Adding the testcase...
>>
>> On 10/7/20 4:08 PM, Jeff Law wrote:
>>> On 9/17/20 1:03 PM, Jakub Jelinek wrote:
>>> [ ... Big snip, starting over ... ]
>>>
>>> I may have not explained things too well.  So I've put together a small
>>> example that folks can play with to show the underlying issue.
>>>
>>>
>>> There's a static library libfu.a.  In this static library we have a hunk
>>> of local static data (utf8_sb_map) and two functions.  One function puts
>>> the address utf8_sb_map into a structure (rpl_regcomp), the other
>>> verifies that the address stored in the structure is the same as the
>>> address of utf8_sb_map (rpl_regfree).
>>>
>>>
>>> That static library is linked into DSO libdso.so.  The DSO sources
>>> define a single function xregcomp which calls rpl_regcomp, but
>>> references  nothing else from the static library.  Since libfu.a was
>>> linked into the library we actually get a *copy* of rpl_regcomp in the
>>> DSO.  In fact, we get a copy of the entire .o file from libfu.a, which
>>> matches traditional linkage models where the .o file is an atomic unit
>>> for linking.
>>>
>>>
>>> The main program calls xregcomp which is defined in the DSO and calls
>>> rpl_regfree.  The main program links against libdso.so and libfu.a.
>>> Because it links libfu.a, it gets  a copy of rpl_regfree, but *only*
>>> rpl_regfree.  That copy of rpl_regfree references a new and distinct
>>> copy of utf8_sb_map.  Naturally the address of utf8_sb_map in the main
>>> program is different from the one in libdso.so and the test aborts.
>>>
>>>
>>> Without LTO the main program would still reference rpl_regfree, but the
>>> main program would not have its own copy.  rpl_regfree and rpl_regcomp
>>> would both be satisfied by the DSO (which remember has a complete copy
>>> of the .o file from libfu.a).  Thus there would be only one utf8_sb_map
>>> as well and naturally the program will exit normally.
>>>
>>>
>>> So I've got a bunch of thoughts here, but will defer sharing them
>>> immediately so as not to unduly influence anyone.
>>>
>>>
>>> I don't have a sense of how pervasive this issue is.   I know it affects
>>> man-db, but there could well be others.
> This is:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=26530
> https://sourceware.org/bugzilla/show_bug.cgi?id=26314

I'm highly confident the fix for 26314 is already in my trees -- in fact
I'm the one that originally reported that to Nick to begin with and much
of that text is mine :-)


I will check 26530.  Thanks for the pointers.

jeff