From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89005 invoked by alias); 3 Apr 2018 22:21:38 -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 88993 invoked by uid 89); 3 Apr 2018 22:21:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-oi0-f68.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Nz6DKzuWKVlIGQW04VYuBx9OxhJjDoOe3TQndZ05h7M=; b=uFt9GYK8FgfZm/ClD0s/V1ulEJU6P2ACKWPtpj1x8r1tBh+pQgJ3aXVQawTsc7XCN4 x2DAdLpTsT0yu/4nQaIo7F7udfpQ6HRm0SiB6y0vzIvypH7X6XjQMLF7GFZz9alRmhxu QuGJUy+Qz/Qd/Coz1M/64LVrLnVv4FGb0UuGy7KJlqnlSV4JXFKF1JAzVHWKaGBvZzkt hUwkC7F+XCl7YChXSYnEoN+aOITgCQmJ8C1qWUwKzPAyG16IZoWCdpcc0EXw2FDWsbqG 7rmMdaZRbVStPcNKupYJSDLbN7R3O9o43ygybRFdhhUz9hZvC7v+nwOQFsoBozdmDQTF Ip7Q== X-Gm-Message-State: AElRT7EZCyl+IOsaDlJVCAAEhFuuoxjPYLPlCU1/pc8a4VtcbkEsSBZz L7zlZucEsvtms+mmYw58NpQFwbiXEFxYFK7Uho6p1w== X-Google-Smtp-Source: AIpwx48lrZ9UpHxkNLWexYzZ6kGPu7bkCD95Tj9Mv6sCa0jn4STUrLybIyI+FSD/EE3t02xKK702NeLt9K6EnZcSBlQ= X-Received: by 2002:aca:478a:: with SMTP id u132-v6mr9089926oia.227.1522794094046; Tue, 03 Apr 2018 15:21:34 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20180403221831.4rtdwr42nihrionc@var.youpi.perso.aquilenet.fr> References: <20180403003817.21337-1-samuel.thibault@ens-lyon.org> <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> From: "H.J. Lu" Date: Tue, 03 Apr 2018 22:21:00 -0000 Message-ID: Subject: Re: [hurd,commited] hurd: Avoid more libc.so local PLTs To: Samuel Thibault Cc: Andreas Schwab , GNU C Library Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-04/txt/msg00093.txt.bz2 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? -- H.J.