This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [hurd,commited] hurd: Avoid more libc.so local PLTs
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?
--
H.J.