On Fri, May 15, 2015 at 04:14:07PM -0700, H.J. Lu wrote:
> On Fri, May 15, 2015 at 4:08 PM, Jan Hubicka <hubi...@ucw.cz> wrote:
> > Hello,
> >>
> >> There are codes like
> >>
> >> extern void foo (void);
> >>
> >> void
> >> bar (void)
> >> {
> >> foo ();
> >> }
> >>
> >> Even with LTO, compiler may have to assume foo is external
> >> when foo is compiled with LTO.
> >
> > This is not exactly true if FOO is defined in other translation unit
> > compiled with LTO and hidden visibility.
>
> I was meant to say " when foo is compiled without LTO.".
>
> > OK, so as I get it, we get the following cases:
> >
> > 1) compiler knows it is generating call to a local symbol a current
> > unit (binds_to_current_def_p returns true).
> >
> > We handle this correctly by doing IP relative call.
> >
> > 2) compiler knows it is generating call to a local symbol in DSO
> > (binds_local_p return true)
> > Currently I think this is only the -fno-pic case or case of explicit
> > hidden visibility and in this case we do IP relative call.
> >
> > We may want to propose plugin API update adding PREVAILING_DEF_EXP.
> > So copiler would be able to default to this case for PREVAILING_DEF
> > and we will also catch cases where the symbol is defined in current
> > DSO as weak symbol, but the definition is not LTO.
> > This would be also way to communicate -Bsymbolic[-functions] across
> > the plugin API.
> >
> > 3) compiler knows there is going to be definition in the current DSO
> > (by seeing a COMDAT function body or resolution info) that is
> > interposable
> > but because the function is inline or -fno-semantic-interposition
> > happens,
> > the semantics will not change.
> >
> > In this case it would be nice to arrange IP relative call to the
> > hidden alias. This may require an extension both on compiler and linker
> > side.
> >
> > I was thinking of doing so for comdats by adding hidden alias with
> > fixed mangling, like __gnu_<function>.hiddenalias, and referring it.
> > But I think it is not safe as linker may throw away section that
> > is produced by GCC and prevail section that is not leaving to an
> > undefined
> > symbol?
> >
> > I think this is rather common case in C++ (never made any stats) because
> > uninlined comdats are quite common.
> >
> > 4) compiler has no clue but linker may know better
> >
> > Here we traditionally always produce a PLT call. In cases the call
> > is known to be hot in the program it makes sense to trade lazy binding
> > for performance and produce call via GOT reference (-fno-plt).
> > I also see that H.J.'s branch helps us to actually avoid the GOT
> > reference in cases the symbol ends up binding locally. How the lazy
> > binding with relaxation works?
>
> If there is no GOT slot allocated for symbol foo, linker should resolve
> foo@GOTPLT(%ebx) to to its PLT slot address + 6, which is the push
> instruction, to support lazy binding. Otherwise, linker should resolve it
> to its GOT slot address.
Forget lazy binding. It's dead anyway because serious distros want
PIE+relro+bindnow+... If people really want lazy binding, they can use
options which support it, but I don't want to keep suffering the
codegen cost of lazy binding despite never using it. There should be
an option to generate optimal code equivalent to what you get with
Alexander Monakov's patches for those of us who aren't trying to
support this legacy feature that precludes good performance and
precludes hardening.
Rich
