static binary, dlopen, and ifunc

H.J. Lu hjl.tools@gmail.com
Fri Nov 13 15:51:13 GMT 2020


On Fri, Nov 13, 2020 at 7:46 AM Samuel Thibault <samuel.thibault@gnu.org> wrote:
>
> H.J. Lu via Libc-alpha, le ven. 13 nov. 2020 07:10:54 -0800, a ecrit:
> > On Fri, Nov 13, 2020 at 7:01 AM Samuel Thibault <samuel.thibault@gnu.org> wrote:
> > >
> > > H.J. Lu via Libc-alpha, le ven. 13 nov. 2020 06:29:28 -0800, a ecrit:
> > > > On Fri, Nov 13, 2020 at 6:27 AM Samuel Thibault <samuel.thibault@gnu.org> wrote:
> > > > > We can as well avoid the problem entirely by introducing an actual
> > > > > __mig_stpncpy function that will not pose ifunc issues. But it really
> > > > > seems to me there can be something fishy here, not really specific to
> > > > > the Hurd.
> > > >
> > > > Functions used by init_cpu_features must not use IFUNC.
> > >
> > > ? That is unrelated.
> > >
> > > Here the problem is that when stpncpy_ifunc_selector gets called to
> > > relocate the stpncpy reference, _rtld_global_ro was not relocated yet,
> > > and thus 0.
> >
> > ld.so.1 should be relocated first.  You need to find out why it isn't the
> > case on Hurd.
>
> Just thinking: here I'd rather say that it's libc.so which doesn't
> get relocated first? The non-relocated reference is inside libc.so's
> stpncpy_ifunc_selector.
>
> Since we do have a loop between libc.so and libmachuser.so, I guess I'll
> just go the __mig_stpncpy way and be done.
>

You need to break the circular dependency.   You should put it in libmachuser.so
so that libmachuser.so doesn't depend on libc.so.

-- 
H.J.


More information about the Libc-alpha mailing list