From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110883 invoked by alias); 2 Oct 2018 21:06:59 -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 110864 invoked by uid 89); 2 Oct 2018 21:06:58 -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=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*f:CAMe9rOqfXXtUF, loader, H*i:sk:3H-TtcP, H*f:sk:3H-TtcP X-Spam-Status: No, score=-1.9 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-io1-f52.google.com Received: from mail-io1-f52.google.com (HELO mail-io1-f52.google.com) (209.85.166.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 02 Oct 2018 21:06:56 +0000 Received: by mail-io1-f52.google.com with SMTP id p4-v6so3303346iom.3; Tue, 02 Oct 2018 14:06:56 -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=eR28x6TagrAOxo35CCQnr6tlLIs2TVD3dcCWqhKIgqQ=; b=WvaMrFwTBNYJctCcj5gpx2faTPdQKOeCIRi1TzT0W+PFq/sHJ2SwfYGjn2+ZUZDZH4 C4zH2zz/e42MQxeDN86IRcm78qNBTdlj+iXDnXxM0TK2R4PqCtQrkORWWiwntEvzXtg6 OtiQzXX9KJc0+9N9U4Pbvbhqmazy5ltAd9hZ25cROAWOerPZig/Ike+yMH4DWrBVR0Z1 WwdXO0m7gBAc/A4EHLa8i4MSOkIqSJbP+zfE9VJQ9sBMm8W5Ye7mxIcM/zfGbgGgRWGU +Qb4naB+bdXxLfYTPBInpbPxc2ZG7ZgbUwjew04Y0/tntJn3t3AcYRS6yWm0T6hJ+j9K uj8Q== 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=eR28x6TagrAOxo35CCQnr6tlLIs2TVD3dcCWqhKIgqQ=; b=bYta6+scGl8PwSrBizONZMg2+uTO1ElIgU3pyJOOWWRH7LlV3visgQa+zJmlUVxYNu SKNClwdQXmSphAYnv+yEpEw7OLp984PSqM2PS3lA003pPLotupNEQLs6DLEMcA4foX8j iaBIuEzMyrpKpgiXYimpyHD5J8A44XMKQ9VP/fL1Cy2I/wp6vj8z7HQ6Lv8prZ/VGSMC hSMgPgXuD+Aoll5OnlLppJ1ZB0xCsdYbfoLpE400Qv8EKuzSvulCGiMCc/mw8d3gRnnq JwHlnkr3+1rcp53OLOdY/faxI5n/pTWXwRiQASynjptGunVbpsqFxCXRxgfO8KO6aSd6 gQgA== X-Gm-Message-State: ABuFfoifErQ5fjDSN6CIWAEtNqXxYh/qH/DufjPBR2GBDb/3V4g7Q5Cv fpC3+VdtCZ9tvK0tQR1HM0TCqYmyAA5kAjwBXeo= X-Google-Smtp-Source: ACcGV60QclGm7gZ4vAaARpsDYI97NVDi0/Vj7Ny9iewnlVho10rU+z6R5VwiIcZVYU5p39l7373AKVTwPdp9QmQDZZ0= X-Received: by 2002:a6b:8d42:: with SMTP id p63-v6mr7087627iod.240.1538514414937; Tue, 02 Oct 2018 14:06:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Cary Coutant Date: Mon, 01 Jan 2018 00:00:00 -0000 Message-ID: Subject: Re: RFC: Add GNU_PROPERTY_NEED_PHDRS To: "H.J. Lu" Cc: Michael Matz , Rich Felker , "Carlos O'Donell" , Florian Weimer , nsz@port70.net, Jan Beulich , Binutils , gnu-gabi@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-q4/txt/msg00008.txt.bz2 > 1. Linker kernel passes AT_PHDR to main and assumes that AT_PHDR > is in a PT_LOAD segment. s/Linker/Linux/ One could argue that this is the real (and only) problem. If it's going to pass a pointer to the program headers, the kernel should make sure that the headers are mapped, whether or not they're part of a PT_LOAD segment. Even with no-separate-code, or with a read-only segment before the text, the inclusion of the program headers in the first PT_LOAD segment is merely a happy accident -- it's a side effect of way the linker rounds segment boundaries down and up to page boundaries, and depends entirely on the property that the first PT_LOAD segment falls within the first page of the executable file. If, for some reason, the linker were to place additional non-loadable stuff between the headers and the text (e.g., symbol tables, section tables), this could fail. In fact, if the program headers themselves happen to be so large as to spill over onto the second page of the file, the first PT_LOAD segment would not necessarily include the first page of the file. Now, I understand that fixing the Linux kernel to map the headers even if they're not part of a PT_LOAD segment isn't a practical alternative. That leads to... > 2. gABI doesn't require phdrs in a PT_LOAD segment. It doesn't belong in the gABI, as the mechanics of making the program header information available to the dynamic loader and the running program are processor- and OS-specific. Since this is a Linux-specific issue, not an architecture-specific one, we really should put this in an osABI document rather than a psABI document. I suppose the LSB serves as such. Or maybe the gnu ABI document? > 3. Ld won't create a PT_LOAD segment just to hold phdrs. You seem to be breezing right past the idea of doing exactly this. Why? The scripting language already allows you to declare which segment should include FILEHDR and PHDRS. For -z separate-code, why not use a default linker script with something like the following? PHDRS { headers PT_PHDR PHDRS ; interp PT_INTERP ; header_seg PT_LOAD FILEHDR PHDRS ; text PT_LOAD ; data PT_LOAD ; dynamic PT_DYNAMIC ; } > 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. How is it intrusive? If the above linker script doesn't do the job, isn't that a bug anyway? And, really, there's no denying that adding an otherwise-unnecessary note section -- just to get us back into the realm of "it works by happy accident" -- is a pure hack. -cary