From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101815 invoked by alias); 3 Apr 2018 22:33:52 -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 101805 invoked by uid 89); 3 Apr 2018 22:33:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: mailbackend.panix.com X-Gm-Message-State: ALQs6tCYO3wwunOlTuwgFD0uY2bXQ7z4RN+7i04OJ4RqclLqf9vH6nLj zgIr8kuzHGD6T2XIzlaajQs+/9jNVvKE2cIKFfs= X-Google-Smtp-Source: AIpwx48bg6yQjxcsbRzl5d0DjDNAq33F6yIb7+3aut0Q2hccyi96flkFujT42eLdU+uQd/nmuHN0Q7EymItT4qqTiX0= X-Received: by 2002:a9d:41c5:: with SMTP id v5-v6mr938433oti.74.1522794827988; Tue, 03 Apr 2018 15:33:47 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20180403222759.5o5pvdgiqqegrxdp@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> <20180403222759.5o5pvdgiqqegrxdp@var.youpi.perso.aquilenet.fr> From: Zack Weinberg Date: Tue, 03 Apr 2018 22:33:00 -0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [hurd,commited] hurd: Avoid more libc.so local PLTs To: Samuel Thibault Cc: "H.J. Lu" , Andreas Schwab , GNU C Library Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-04/txt/msg00096.txt.bz2 On Tue, Apr 3, 2018 at 6:27 PM, Samuel Thibault wrote: > Zack Weinberg, on mar. 03 avril 2018 18:21:10 -0400, wrote: >> On Tue, Apr 3, 2018 at 5: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? >> >> 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). Joseph would know better than me, but I _think_ it's still necessary to avoid using the application-namespace names. For instance, a program that uses fork, but not siglongjmp, might have defined its own siglongjmp -- this actually isn't that farfetched if you consider things like gnulib (and I do know of a few cases where gnulib will override a glibc function with its own implementation). zw