From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87880 invoked by alias); 3 Apr 2018 22:21:15 -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 87869 invoked by uid 89); 3 Apr 2018 22:21:14 -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=ungodly X-HELO: mailbackend.panix.com X-Gm-Message-State: ALQs6tCZr4AD771mVthJrAoyT4zTW4xmYHbFnoe9gDsWM8qy3aBqo3g8 nBXp6t1VQDwo5srNFsc0xMTpDrPvcYWsLCIRvmE= X-Google-Smtp-Source: AIpwx49ndqJiVPCleaeGh5+6XAOnisqhQqrMYbxlh3HlRM2dnC5aq1IqVxMYyYO3SsLmvySjs88muYvpIJM+EYJd+b4= X-Received: by 2002:a9d:73c1:: with SMTP id m1-v6mr9816331otk.166.1522794070842; Tue, 03 Apr 2018 15:21:10 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20180403215502.gecm7xl2gnw7xwxc@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> From: Zack Weinberg Date: Tue, 03 Apr 2018 22:21: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/msg00092.txt.bz2 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. These are the rules as I understand them: First, any internal call to a function that is not in C89 probably has to call a __-prefixed name, or you will fail the checknamespace tests. The principle here is that a strictly-conforming C89 program _could have_ defined the unprefixed version of that name and we don't want that to interfere. This is true even if the unprefixed name has a hidden_proto annotation, because those have no effect on static linkage. There are exceptions to this rule but I do not understand them well enough to explain them. Second, if an internal function is defined in libc, and should only ever be called from within libc, then it should be given a name that starts with __ but not with __libc_, and should be declared with attribute_hidden on its prototype, but does not need hidden_def/hidden_proto annotations. This is the simple case for avoiding unnecessary calls through the PLT. Third, if an internal function is defined in libc and called from both inside and outside libc, but still not by applications, you declare it *without* attribute_hidden on its prototype and use libc_hidden_def and libc_hidden_proto, and you still use a name that starts with __ but not with __libc_. That bypasses the PLT for internal calls but leaves the __-name callable from outside libc. (It may also be necessary to add the function to a GLIBC_PRIVATE section of a Versions file.) The names that start with __libc_ are needed in even more unusual cases, such as when functions need to be defined in both libc and libpthread. I am actually trying to clean this up right now and it is an ungodly mess. libhurd and libgnumach are lower-level than libc, IIUC, so the most important thing for them is the first principle: make sure not to stomp on the application namespace in static linkage. You can decide how important PLT bypassing is to you. zw