From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) by sourceware.org (Postfix) with ESMTPS id 95AAE3858421 for ; Thu, 18 Nov 2021 12:49:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 95AAE3858421 Received: by mail-ua1-x92b.google.com with SMTP id p37so13310479uae.8 for ; Thu, 18 Nov 2021 04:49:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=rK9aLzEgJkRApIWJxjeIx7KMsG+z2ySEaJlndXDauRQ=; b=XRA8F1SUSRq00Ss3IZbTLUlMd0zR8Vpgyj+r+MwNOwdIBwTII0UEV4fh3S8Ujby0nw 5bBFAZw1v1TPpAWuqZ4bYT5LeTmafb1oDrOBbFEKOXsFkswc0qhFjq8/V9EUGJCFsfp1 4HcKXjSYvK0QaGlWUnrs3uv6Tn1xJ+Urmp2a67D0DbCSCe6FryjUoijS7jLTtIrqfq+w 65IL/IWHtGel4ZNXgWSYnOeWz5k9wW+MYEaGoLzpOaHMsTIOgkeWEn7duveH+Zfk3ZRW QkGihaI5WA6A/rzxAe2lhV2UqK+pQo6zltxWX5wgW/XuTnnfOHt1gT94wqDpjIDHj01S FjyQ== X-Gm-Message-State: AOAM531UN/VouAibuAkNy1Y2jvIYqo1aTh5PR44ImSvJdge5ug2jEHpz T+44ITVprN/xboIPEY6bBDDAiQ== X-Google-Smtp-Source: ABdhPJxFVOtGbAbYKuBVxDc6pqfnN3qooxl5smjYWHsDti1XLIClnFCi3XoNdn1mhAES8iprDsUo6g== X-Received: by 2002:a67:d28b:: with SMTP id z11mr80912131vsi.49.1637239793019; Thu, 18 Nov 2021 04:49:53 -0800 (PST) Received: from ?IPV6:2804:431:c7ca:66dc:202f:4b8d:b771:d283? ([2804:431:c7ca:66dc:202f:4b8d:b771:d283]) by smtp.gmail.com with ESMTPSA id l28sm1534116vkn.45.2021.11.18.04.49.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Nov 2021 04:49:52 -0800 (PST) Message-ID: Date: Thu, 18 Nov 2021 09:49:50 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: [PATCH] New option --enable-pie-programs Content-Language: en-US To: "H.J. Lu" , Siddhesh Poyarekar Cc: Florian Weimer , Siddhesh Poyarekar , GNU C Library 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> <07d2bb89-93c7-54b0-dec6-7fdbd4e4998e@gotplt.org> From: Adhemerval Zanella In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=unavailable 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 12:49:55 -0000 On 18/11/2021 09:42, H.J. Lu via Libc-alpha wrote: > On Thu, Nov 18, 2021 at 1:24 AM Siddhesh Poyarekar wrote: >> >> 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.? > > How about --enable-default-pie? Another option would be to --enable-pie= where 'no' disables PIE for both both static and dynamic installed programs and 'auto' checks compiler support and enables for everything. I would like to provide less options which results in less permutations to test.