From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-91399-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 95464 invoked by alias); 3 Apr 2018 22:28:05 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 95330 invoked by uid 89); 3 Apr 2018 22:28:04 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_NEUTRAL autolearn=no version=3.3.2 spammy=Hx-languages-length:1714
X-HELO: hera.aquilenet.fr
Date: Tue, 03 Apr 2018 22:28:00 -0000
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Zack Weinberg <zackw@panix.com>
Cc: "H.J. Lu" <hjl.tools@gmail.com>, Andreas Schwab <schwab@suse.de>,
	GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [hurd,commited] hurd: Avoid more libc.so local PLTs
Message-ID: <20180403222759.5o5pvdgiqqegrxdp@var.youpi.perso.aquilenet.fr>
References: <20180403003817.21337-1-samuel.thibault@ens-lyon.org>
 <mvmo9j07lsi.fsf@suse.de>
 <20180403082029.g3bfw4upbti67wwz@var.youpi.perso.aquilenet.fr>
 <CAMe9rOoAeQbv6b-1hSTQ9b-EgiC5ErHO3UkS-aZFCFYLn7_xOQ@mail.gmail.com>
 <20180403210755.rbbjx7mou47mp3er@var.youpi.perso.aquilenet.fr>
 <CAMe9rOo_aDsrtY-QfFz-yAp+0-Qg7MW0jGKns7GVjKZ_fTr1=Q@mail.gmail.com>
 <20180403212413.n64u3uvhcem3db47@var.youpi.perso.aquilenet.fr>
 <CAMe9rOqqimSKb+nxR3daeqataHabDHMm-XLWG+_0V7WW2WrtXw@mail.gmail.com>
 <20180403215502.gecm7xl2gnw7xwxc@var.youpi.perso.aquilenet.fr>
 <CAKCAbMjc=sqF+PjvJkjaBygXFWMevBfij-be9kMeWS2ZGd=twQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAKCAbMjc=sqF+PjvJkjaBygXFWMevBfij-be9kMeWS2ZGd=twQ@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
X-SW-Source: 2018-04/txt/msg00094.txt.bz2

Zack Weinberg, on mar. 03 avril 2018 18:21:10 -0400, wrote:
> On Tue, Apr 3, 2018 at 5: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?
> 
> Right, except it has to be the __ variety for siglongjmp because that
> function is not in C89.

Yes, but longjmp and siglong are only used in functions which are part
of _GNU_SOURCE, and longjmp only for fork(), so that implies their
presence, right?

(I would have already gotten the link namespace warning otherwise).

Samuel