From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id a138072c for ; Mon, 3 Feb 2020 04:33:05 +0000 (UTC) Received: (qmail 17670 invoked by uid 550); 3 Feb 2020 04:33:03 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 17646 invoked from network); 3 Feb 2020 04:33:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1580704371; bh=D4X0UJtc07zwUTTMAaLsnwFIw89RGKlraZcCXmnlBYI=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=kUxGRVqJPh5Ew233m2cbIkzQTlPgIHKuMy08rilWCyKDICbURLx3l/Aw1LW0nUwgt IVxiX9+FlR8Ct6h9blkrc2RNyLzkGtLuU4KZn/x2lD0VLFEPWUTGt/aSgzc13ARNNz E8IpA/RahHn7POV7nnxZGd/hXlkVyiqXqYWcNg2s= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Mon, 3 Feb 2020 05:32:51 +0100 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20200203043251.GM2020@voyager> References: <20200129191946.GI2020@voyager> <20200130170249.GK2020@voyager> <20200203031036.GL1663@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200203031036.GL1663@brightrain.aerifal.cx> User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:cGgCbcCPH/SSF9bj0pB2T30Qf0afOlLhYqLVxVTUynY0BYx8Xbt dbtoo6wqXJiPExCLVqvQvw2m4FJacybmTsdrAQOUb3APDpVVGq1H+j/Um1vkMuvGgQDhUXT aPfkwAUD4SQ0GU8xJEJ+gS9U226h6CWuuHtdyZQK7mKPS8LZrld8mjDixIYTyX7wEeZ3N90 EbDCCr8BnwcF/Xqn2Z8Yg== X-UI-Out-Filterresults: notjunk:1;V03:K0:cSMbBJZrYno=:hUaRyS+TfXOhhj6zJ90Mfw Jx9pZOHWWCSf6oW56kqfHO2DU79C6ycnS0ZuH98hOsSKeleSibrrt6OE3aFaDmp6/GwYg1za/ FjZFRar1UyD+l8W3IYBElqJSXn5Yb69+vM+akcjj1R4mCEY0Xb8jukXTn/fBEFcPmuHIn3fGd 1M+mEuAaU45sd8aQDF/PafN6MF5aSK1/VatKHsoVn16HWdr9stEGTw4ixweYhmPV5DSTw/jVh pmc0Ni8l2EycG8IJHumhasUjL7UfKJis05/f+92X3uizUU725wlW8E3YBEY9hDa6M/WcYCeY2 sfHdv55fC7RaPD0LX4DRwC4kRvYjA3HUQ1EkdKV1VuTpzTEeM+pSlLvlgFi0gyGpcu9srDhZp ODMMfkcqguS9SE5X11IFlk1hhJICEC9pg3AwKqrp7q5Kb1grpavfmbk3S7Hm7dAgVGQTJRPdx AFlcWVau9Zq/OtjdI7FC8qtyTYYI3R0ukILSrm233J9Fyhzj75/l2swWNfX3FvSTPCnsItpWj te8La+cFt9Ennvgp5On3J1VclTPBlMdXWq/If9JlCepolgSDq/kmTd6kzUrIKFJpJ9oKE1Pyt A890H07oSLNOs+X0qo0au+T0SfwZe62jNwKwn5zRXmGtVlPTXXiAnxgL2U5ogVGQbWKUibEyK xmxI4AgDggkcxFTcwE3Mz1PfxUXbSZxUIuKVMYxiE6UMhGdmcuQr9aixDdon02Q2TYaNZJjst fY8xlzDi4pQFa8e5ljfizo7nSu2xmPe9viVooKfdJUWzZcBwQv5/NPRvhBPmscpSTBuy0DZzO zOWMdcGbFasPysKk6gJi/ka+4RalHqd/vLTdPWfTHmvnmaD+c+SXtzaD8Je0FOKCmwURZ7tBv DUhgBX6XPpbA5f+EaSsAoFS6QhSjMfexcBJUOEcKTY+s4IUdaIYAcdiVHrBalXhaCYQwAfH75 9ZGRP+Sd//B7pYIkDgYM+CVxK18O6/ON8X2nsfBC9ARPrxdhuU9iZGZV32a5r5Gc//0YSl41w 588okr1yaDAQmpVxOlTUJqXvoHBFAhehC/ptsC7SzT7JEsBBANR27vez55ImK7enSIGQfPI0W 5fa0h4BgwUvARU0dzygU67JlmBJqpJCVG2h45/hQgyeOK4MEBqlrhshP1CBplUg5kOmKHWJy3 y0KtzgNs56iw5m+Z6kxBN/8EDrug/8k3XUn1ECzSlVQsvloQ4pTxzQxHZJDB9nbCipcc4bfqz qmiFrNs5TSV+spNod Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Static linking is broken after creation of DT_TEXTREL segment On Sun, Feb 02, 2020 at 10:10:36PM -0500, Rich Felker wrote: > I'll probably end up having mcm pass --with-pic to GCC's top-level > configure, but I see this will be picked up by some other libs like > libcc1, which oddly aren't failing for the same reason. Any idea why? I'd guess they don't use assembly, or at least their assembly does not try to access global symbols. I haven't looked at the source though. And I won't until the afternoon at least. > Is this the right fix for mcm? What could/should be done to unbreak > gmp with default-pie toolchains? Is it a bug in the version of libtool > they're using or a bug in gmp? > > Rich The problem is with the assumptions of GMP. And I really don't know how to fix those. GMP's build system generates a dynamic and a static library, and assumes that the static library does not need to be PIC. With the advent of static-pie, this assumption is subverted. But how to deal with this generally? Many libraries assume the static one does not need PIC. And while PIC has little to no overhead on AMD64, other architectures are not so forgiving. For example, on PowerPC, you need to set up a GOT pointer first, which requires spilling the link register, calling the next instruction so you can get its address, adding the offset to the GOT to that, then adding the GOT relocation to that. So you get the non-PIC code: lis rX,sym@ha addi rX,rX,sym@l turning into the PIC code: mflr r0 bcl 20,31,1f 1: mflr rX addis rX,rX,(_GLOBAL_OFFSET_TABLE_ - 1b)@ha addi rX,rX,(_GLOBAL_OFFSET_TABLE_ - 1b)@l mtlr r0 lwz rX,sym@got(rX) (Wait, can sym@got exceed 32k? Then that last instruction turns into two instructions again.) It would be hard to argue that the latter is as efficient as the former, is my point. In case of GMP, I would argue they can add a test to determine if the toolchain generates static-pie, and turn on PIC by default if so. No clue if upstream will like that, though. Ciao, Markus