Problem with static const objects and LTO
H.J. Lu
hjl.tools@gmail.com
Wed Oct 7 23:12:54 GMT 2020
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
--
H.J.
More information about the Gcc-patches
mailing list