From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106191 invoked by alias); 27 Sep 2018 22:35:02 -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 106151 invoked by uid 89); 27 Sep 2018 22:35:01 -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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=aux, Hx-languages-length:1024, our X-Spam-Status: No, score=-1.9 required=5.0 tests=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-io1-f54.google.com Received: from mail-io1-f54.google.com (HELO mail-io1-f54.google.com) (209.85.166.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 27 Sep 2018 22:35:00 +0000 Received: by mail-io1-f54.google.com with SMTP id y3-v6so3037543ioc.5; Thu, 27 Sep 2018 15:35:00 -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=E3XmtQI4fR3cI7D3jDgHSAV14OnlsnrvpgHfLukMTew=; b=ScvEVmPTXenkD8L1tN5ndNNn/8Auv23MZE9iBgolSHtfGqZctCOOog7QLETjTm5DWE 1/HL89HBGmCChYABhZhx3rOVRgM2bmcc1sSUp0NmedN9nj3My12diUR2C64+ic2SThGU bKK+I5R8ZtJOIuJMXYu1oL8Deehf+R6A6LzcOACxqNArEf8C7awEYAxCWLepi7vqy4tN EnDwGc43EowFFlBSgHVxwnyZ9vkCyZ6ieTYg1yfKOxlC9R+IQes0twmOYjdXO2AZFFw8 py5VRWhZtU9T4L754Z2dkst735i2iJFJCQLnp2XBz/n4BJXfLO23npOi1VDdcGC20qS5 t/aA== 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=E3XmtQI4fR3cI7D3jDgHSAV14OnlsnrvpgHfLukMTew=; b=AE8NBUIXI0l9CDMcf/uYlyz65mE2wsUbwKbBldMSY5kF+0XWBkYTeIXsApZYyDkUsU M0g+7a+ERNxilfnZjUyrUSCCO0kTu0BiLWZknxMR/d8CJxU0flQY2tfuU/rHWqK+jyKZ 1t/pMExuZUAORjJu1x85YnWNiOk0lrJr+EKREVGblZts+3aVB1pgcV73RyKqg5pvs2P4 LZf8bgLPkxRH9zdHDwFHxla+VZYo/iBHFmlZ7DnDvIy2J4o2spGmIqTKuiniMIA8dQl2 P08S++qYFGJY4dQ28n8jPUK/N4YB/Sduqs40AuZIA5S3A2l6cRQZbFjg5lTZu2Av/4h4 lVow== X-Gm-Message-State: ABuFfohZPbk+Iu+z+iPXdNiROokxa0TJXWyZc599mOLuTcuE8/Let0/V c5gF7Um97UiRk/vlNv+/Kc1w43Ta00vLW1PKU7c= X-Google-Smtp-Source: ACcGV63quIAh225+w0hmaqJSscgBR9GIQCKtkIYAed4T2Z/rccqE3X+T6vmYSAW8DTs1C55d2XlsIf8miaLZN5xo0YQ= X-Received: by 2002:a6b:1b53:: with SMTP id b80-v6mr9998639iob.48.1538087698421; Thu, 27 Sep 2018 15:34:58 -0700 (PDT) MIME-Version: 1.0 References: <87tvmbv8hp.fsf@oldenburg.str.redhat.com> <5BAC7D6802000078001EC6D1@prv1-mh.provo.novell.com> <87pnwzuz8r.fsf@oldenburg.str.redhat.com> <20180927103539.GJ10209@port70.net> <87va6rqfg6.fsf@oldenburg.str.redhat.com> <87r2hfqes1.fsf@oldenburg.str.redhat.com> <73bd396c-43be-2922-fce4-17ee835d862e@redhat.com> In-Reply-To: <73bd396c-43be-2922-fce4-17ee835d862e@redhat.com> From: Cary Coutant Date: Mon, 01 Jan 2018 00:00:00 -0000 Message-ID: Subject: Re: RFC: Add SHT_GNU_PHDRS To: "Carlos O'Donell" Cc: Florian Weimer , "H.J. Lu" , nsz@port70.net, JBeulich@suse.com, Rich Felker , Binutils , gnu-gabi@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-q3/txt/msg00025.txt.bz2 > > I'm now under the impression that the bits that are PT_LOAD'ed all need > > to be covered by (allocated) sections. A zero-sized section doesn't > > cover anything, so it doesn't address this requirement of the ELF > > specification. > > I agree. What we did in the past by relying on phdrs to be accidentally > in the first PT_LOAD segment always irked me as bad design. > > If we need access to program header we need clear semantics for doing so, > not hackish kludges to force the linker to get it onto a page that also > happened to be mapped. This is just poor engineering on our part. It seems to me that the kernel loader should make the program headers available to the dynamic loader through the aux vector, whether they're part of a PT_LOAD segment or not. That should be part of the psABI. The gABI clearly requires that the dynamic loader has access to the program headers (e.g., it needs to find PT_DYNAMIC), but it doesn't care how the implementation accomplishes that. -cary