Re: [hurd,commited] hurd: Avoid more libc.so local PLTs

[Samuel Thibault <samuel dot thibault at ens-lyon dot org>]

H.J. Lu, on mar. 03 avril 2018 15:21:33 -0700, wrote:
> On Tue, Apr 3, 2018 at 3:18 PM, Samuel Thibault
> <samuel.thibault@ens-lyon.org> wrote:
> > H.J. Lu, on mar. 03 avril 2018 15:14:16 -0700, wrote:
> >> On Tue, Apr 3, 2018 at 2:55 PM, Samuel Thibault
> >> <samuel.thibault@ens-lyon.org> wrote:
> >> > H.J. Lu, on mar. 03 avril 2018 14:41:27 -0700, wrote:
> >> >> On Tue, Apr 3, 2018 at 2:24 PM, Samuel Thibault
> >> >> <samuel.thibault@ens-lyon.org> wrote:
> >> >> > H.J. Lu, on mar. 03 avril 2018 14:16:50 -0700, wrote:
> >> >> >> On Tue, Apr 3, 2018 at 2:07 PM, Samuel Thibault
> >> >> >> <samuel.thibault@ens-lyon.org> wrote:
> >> >> >> > Hello,
> >> >> >> >
> >> >> >> > H.J. Lu, on mar. 03 avril 2018 12:26:33 -0700, wrote:
> >> >> >> >> __libc_longjmp and __libc_siglongjmp are private external functions provided for
> >> >> >> >> libpthread.  They should never be called inside libc.
> >> >> >> >
> >> >> >> > I'm sorry for asking, but are these conventions documented somewhere?
> >> >> >> > These look like magic to me otherwise:
> >> >> >>
> >> >> >> I don't believe they are well documented.
> >> >> >
> >> >> > Ok, then I need an answer to my question:
> >> >> >
> >> >> >> > why shouldn't they ever be called from libc?
> >> >> >
> >> >> > The existing hurd code does use them for catching signals, so I need to
> >> >> > know how to fix it.
> >> >>
> >> >> Use something similar to
> >> >>
> >> >> libc_hidden_proto (_setjmp)
> >> >> libc_hidden_proto (__sigsetjmp)
> >> >
> >> > So I'd just add hidden protos & defs to longjmp and siglongjmp?
> >> >
> >>
> >> setjmp/longjmp.c has
> >>
> >> weak_alias (__libc_siglongjmp, _longjmp)
> >> weak_alias (__libc_siglongjmp, longjmp)
> >>
> >> Will
> >>
> >> libc_hidden_proto (_longjmp)
> >>
> >> work for you?
> >
> > Well, _longjmp is the BSD version of longjmp with the semantic of
> > siglongjmp (actually it's _setjmp which makes the semantic different,
> > recorded in the jmp_buf). Here we do use longjmp, not _longjmp. Of
> > course, the end pointer is the same since it's _setjmp which makes
> > the semantic different, but I'd really rather not make the code more
> > confusing by using _longjmp while it is actually a longjmp which is
> > meant.
> 
> Aren't  the internal symbols of _longjmp, longjmp and siglongjmp
> pointing to the same __libc_siglongjmp function?

As I wrote above, yes.  But as I wrote above, writing _longjmp in some
source code which actually means longjmp would be very confusing (as
well as exposing a BSD symbol)

Samuel