From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97483 invoked by alias); 3 Apr 2018 22:30:00 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 97462 invoked by uid 89); 3 Apr 2018 22:29:59 -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= X-HELO: hera.aquilenet.fr Date: Tue, 03 Apr 2018 22:30:00 -0000 From: Samuel Thibault To: "H.J. Lu" Cc: Andreas Schwab , GNU C Library Subject: Re: [hurd,commited] hurd: Avoid more libc.so local PLTs Message-ID: <20180403222954.zcniys5ujh4ryrvm@var.youpi.perso.aquilenet.fr> References: <20180403082029.g3bfw4upbti67wwz@var.youpi.perso.aquilenet.fr> <20180403210755.rbbjx7mou47mp3er@var.youpi.perso.aquilenet.fr> <20180403212413.n64u3uvhcem3db47@var.youpi.perso.aquilenet.fr> <20180403215502.gecm7xl2gnw7xwxc@var.youpi.perso.aquilenet.fr> <20180403221831.4rtdwr42nihrionc@var.youpi.perso.aquilenet.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-SW-Source: 2018-04/txt/msg00095.txt.bz2 H.J. Lu, on mar. 03 avril 2018 15:21:33 -0700, wrote: > On Tue, Apr 3, 2018 at 3:18 PM, Samuel Thibault > 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 > >> 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 > >> >> 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 > >> >> >> 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