From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89492 invoked by alias); 2 Oct 2018 16:23:36 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 89472 invoked by uid 89); 2 Oct 2018 16:23:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.1 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-ot1-f41.google.com Received: from mail-ot1-f41.google.com (HELO mail-ot1-f41.google.com) (209.85.210.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 02 Oct 2018 16:23:34 +0000 Received: by mail-ot1-f41.google.com with SMTP id o21so2193650otb.13; Tue, 02 Oct 2018 09:23:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0E9uIRIeI4ovU8fVts8Wu83ErnrZokRIfBvNq8F+5cs=; b=ZmSdrZtdg6QHRbE5U4gmwNjYbDc2C6IDBFHycHadYD6PmJUY6aivO5MIh6t7ux7SI/ LXiFGxnv4i0x4UIyVVIw69H++T+yuUNY0fI3A4PxoA+Dflskb/s5Auo4iChs1TSftEUA pJCMJs10GT0wZRqzwug7ra1LCCKZgTcJPy2iVRDS29b+wQyc3wJ4adIfOnCAa/WDSGdb SigAIc62XNer2aN0mR17BcoiFPbJgffuOzkoEzavSE5aZDMG+fbbPTvlVzCwi4k556v9 1TpNSyhkIIttMnfeHn241Vb1oMb3ibxbGhbADdG7tV/t6gjmIbZc8pPosdFRixJE7oGe CHYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0E9uIRIeI4ovU8fVts8Wu83ErnrZokRIfBvNq8F+5cs=; b=lBsAKWRWtS2s7HnqyC1+XGDh6wIaH36Ujpp+Y8wlZgZkjyDEzojuXE70GJ/3DCPlkU IIcKfimvy5WNHq7WmkI+s4ZMLqDmf+EcrN+nK9a7A2iPmP5IAcq7GsvVt0QvBPgpNwvE +36xmxolc5ARLuInK1WKtKUj1Ofr63ffo3FGNAHAcF3/mRVrVT2anHXOVpbrzwk255M6 YQL+0JyFceAPrKehuGhWxeEkxHpxByOZB8tfLkiFEFKid2TOAHZPg9g+u5Lo57K1G+9/ ASUaQ0sTGJi6RT3pfYI+2L0NyVAO0IOE06j20DMpy6JPCwRO520Ejmty1iIRU2qitbIs qVHw== X-Gm-Message-State: ABuFfoiPOq3ogAaHljAfRAdnzMo8yyd1vktc7HaRFV9NnjYYZbx6LwH/ 7EY3uZFZ4EvNsYGFvPEVcCA6vT3voHFJWv8GNs4= X-Google-Smtp-Source: ACcGV60pNR346vk4ypG71TQgJHOs6GH0aL9zFF7bcMWrP4n55uUNRibpgR4LOMFDVVualGsXP46+6EO1LbGjNSOd8sQ= X-Received: by 2002:a9d:2f06:: with SMTP id h6-v6mr10349807otb.4.1538497412337; Tue, 02 Oct 2018 09:23:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "H.J. Lu" Date: Mon, 01 Jan 2018 00:00:00 -0000 Message-ID: Subject: Re: RFC: Add GNU_PROPERTY_NEED_PHDRS To: Michael Matz Cc: Rich Felker , Cary Coutant , "Carlos O'Donell" , Florian Weimer , Szabolcs Nagy , Jan Beulich , Binutils , gnu-gabi@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-q4/txt/msg00007.txt.bz2 On Tue, Oct 2, 2018 at 8:48 AM Michael Matz wrote: > > Hi, > > On Tue, 2 Oct 2018, H.J. Lu wrote: > > > > > If linker script discards a section, all bets are off. Anything can > > > > happen. > > > > > > I disagree, but even if I'd agree your solution still is more > > > accidental than by design. You want to guarantee something about > > > program headers, so any solution that doesn't do anything specific > > > about/with program headers is similarly accidental. > > > > Nothing is guaranteed when linker script is used since anything can > > happen with linker script. > > Ignore the parts about the linker script, I disagree with you, but that's > immaterial to my main point. Your solution still is only an accidental > one as you don't do anything about program headers but instead just add > magic sections to magic places that happens to do what you want currently. > That's not by design. The problem is 1. Linker kernel passes AT_PHDR to main and assumes that AT_PHDR is in a PT_LOAD segment. 2. gABI doesn't require phdrs in a PT_LOAD segment. 3. Ld won't create a PT_LOAD segment just to hold phdrs. 4. With -z separate-code, linker won't put any non-code in a PF_X PT_LOAD segment. When there are only PF_X PT_LOAD segments, phdrs isn't in any PT_LOAD segment. You are looking for a solution to create a PT_LOAD segment just to hold phdrs. I have investigated it. It is very intrusive. My solution, which you called a hack, is to add a read-only SHF_ALLOC section so that a PT_LOAD segment will be created by ld to hold phdrs when there is only PF_X PT_LOAD segments otherwise. -- H.J.