Problem with static const objects and LTO

[Jeff Law]

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.
>
>
>
>
> jeff
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.tar.gz
Type: application/gzip
Size: 859 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20201007/45f359a7/attachment.gz>