From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from burlywood.elm.relay.mailchannels.net (burlywood.elm.relay.mailchannels.net [23.83.212.26]) by sourceware.org (Postfix) with ESMTPS id 54ADB3858C2C; Thu, 18 Nov 2021 09:24:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 54ADB3858C2C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 9B2997812FE; Thu, 18 Nov 2021 09:24:22 +0000 (UTC) Received: from pdx1-sub0-mail-a305.dreamhost.com (100-96-18-151.trex.outbound.svc.cluster.local [100.96.18.151]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 04B49781B03; Thu, 18 Nov 2021 09:24:22 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from pdx1-sub0-mail-a305.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.96.18.151 (trex/6.4.3); Thu, 18 Nov 2021 09:24:22 +0000 X-MC-Relay: Junk X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Irritate-Ruddy: 2825170d5598f2b5_1637227462279_2139972242 X-MC-Loop-Signature: 1637227462279:483484400 X-MC-Ingress-Time: 1637227462278 Received: from [192.168.1.174] (unknown [1.186.223.33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a305.dreamhost.com (Postfix) with ESMTPSA id 4HvvWS0Vbvz1Tx; Thu, 18 Nov 2021 01:24:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gotplt.org; s=gotplt.org; t=1637227461; bh=dRIcZfK+VlzS7T7ATP0mforIX48=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=gN/Ps2swvEaaMW/7Yf6KOAX2k9hjS5pzjyBVJvVdb1FEgzXcz+VMyURiywG6zDUM0 P5pBKEU0H+tsDsKkrLuMyHbuescwOLIfLxPD3ECXzMsJC9dmIKYK9FyqbcY8LwNNMG rEgci9N+BuuIoxvz/Yq77ebMavd7pwAfKzQtENYo= Message-ID: <07d2bb89-93c7-54b0-dec6-7fdbd4e4998e@gotplt.org> Date: Thu, 18 Nov 2021 14:54:13 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0 Subject: Re: [PATCH] New option --enable-pie-programs Content-Language: en-US To: Siddhesh Poyarekar , Florian Weimer Cc: libc-alpha@sourceware.org References: <20211116135240.3092651-1-siddhesh@sourceware.org> <87czn0cicn.fsf@oldenburg.str.redhat.com> <875ysr9nwo.fsf@oldenburg.str.redhat.com> <87wnl787vg.fsf@oldenburg.str.redhat.com> <4e9ac2de-aa3d-d9bf-c838-74e8fb59ead5@sourceware.org> From: Siddhesh Poyarekar In-Reply-To: <4e9ac2de-aa3d-d9bf-c838-74e8fb59ead5@sourceware.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3028.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_BL_SPAMCOP_NET, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2021 09:24:26 -0000 On 11/17/21 15:34, Siddhesh Poyarekar via Libc-alpha wrote: > I suppose you're right.  That is current behaviour with > --enable-static-pie too; wouldn't a similar argument hold for > --enable-static-pie=no?  Or is the rationale in that case is that > *static-pie* is disabled, not pie itself and hence the default PIE > toolchain could get away with building PIE dynamic programs, just not > static ones? > > I wonder if the clearer option is to have a new > --enable-pie=, where "no" disables PIE (even on > default-PIE toolchains), "dynamic" enables PIE for dynamic programs and > "full" or "yes" enables static-pie on architectures that support it, > terminating with an error if it's not supported.  --enable-static-pie=no > could then imply --enable-pie=dynamic and could be deprecated.  I don't > remember if we have ever deprecated configure flags before. > > Even simpler, we could have just a yes/no option and enable static-pie > transparently on architectures that support it, making an explicit > --enable-static-pie=no equivalent to disabling all PIE.  It may in > theory break a use case but I don't know if there's actually a use case > where one would strictly want only dynamic PIE and not static PIE. A third option (as we discussed offlist yesterday) could be to always build glibc dynamic programs as PIE as long as the toolchain supports it. Would non-distribution use cases be adversely affected by not having an option to produce non-PIE glibc programs, e.g. iconvconfig, getconf, etc.? Siddhesh