From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90441 invoked by alias); 22 Jun 2018 21:28:53 -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 90429 invoked by uid 89); 22 Jun 2018 21:28:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.4 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=Isnt, H*r:sk:128-v6s, Isn't, Divide 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-HELO: mail-vk0-f44.google.com Received: from mail-vk0-f44.google.com (HELO mail-vk0-f44.google.com) (209.85.213.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 22 Jun 2018 21:28:50 +0000 Received: by mail-vk0-f44.google.com with SMTP id 128-v6so4707626vkf.8 for ; Fri, 22 Jun 2018 14:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rkF/ZLx53Mk5PoIve0plQbeLh4ltFGWPyFokLOhUeBI=; b=jYLdZqBNmyFlqSPcfrMmy2KdX3pn5kw+eufYEU0wjBXd1N3YPj+x/+yNoTsBBZ+L4Z qFwcZ7BusE8qAvpYwD2MGp+uebPpuIVJUZixHE9vZLxasCiXC96bvmG2KCvbgMZ11pvh 9JV+AWwOCjUvDH3NA1PvXXJWgktu1wCAv6PBh5ESSdVk0kvcINUxpgbkkrAc5aD4Y5vt l2h7heCDTzEZVckrBE30nvB2E7PcTew9oGy5mTQmSpqphwshOb1YOqsvr45lpAEQfNtW 7rHanBiRtGWs2auebkwpKvIZEscgR+iKle6ttclWW77cmPzZiHAxMyfQCKYJpjMKyDpN CvEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rkF/ZLx53Mk5PoIve0plQbeLh4ltFGWPyFokLOhUeBI=; b=VfVoKB1XY4Nzi5oFlBjg4XYJxZteIDASdl+dHykyk9mG6bNphD8XDvFYWrWZVNsyJl nF6kUQV5Y/KjiQqb2sKrJ3z0gyW2oDIhkDCtUqx2elXc+p7Pnv3ZwdQbAsBi+EqLhg2E hCmgg93piX0dYyP70jyWdL78qlDCGFSt5PTfMm+f9U2R2NPF2p6uKdgNvNwMBNmHnZBS 0asQSmQpPyoM99rZS76RlZyDzZ/Dthffzw4Y4sUGGntSWZ/hHJa/YwykZO815j3gkOMr cNqRcwWW+kg0jAnQJ6bnB4FeVGpcJcD2QuuMgxBdWg+u5J7Gp+tgIaVjkb5hDnTE34ZE ZPFA== X-Gm-Message-State: APt69E3xWNIZlPF3Plt6YRH8WCajYhT+coCNP9PJGjXipuPrhzEjbjCj YnSKD2O7cVMArtdFem6V+7Ei2Qq7s5EG+ufTotM= X-Google-Smtp-Source: ADUXVKI/FJM1xbRss1oegkaWNYclba/hd6FoWrpKXA7MZScesOHe6b4tnxd2dnvm5WfZ+kY3daKMw0yxcUv7+Hl9ddY= X-Received: by 2002:a1f:8bc6:: with SMTP id n189-v6mr2022655vkd.104.1529702929128; Fri, 22 Jun 2018 14:28:49 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a67:d90a:0:0:0:0:0 with HTTP; Fri, 22 Jun 2018 14:28:48 -0700 (PDT) In-Reply-To: <83d583d0-884e-4208-436e-5b25cbb6ce5a@redhat.com> References: <87sh5hadd6.fsf@redhat.com> <83d583d0-884e-4208-436e-5b25cbb6ce5a@redhat.com> From: Cary Coutant Date: Mon, 01 Jan 2018 00:00:00 -0000 Message-ID: Subject: Re: RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END To: Nick Clifton Cc: gnu-gabi@sourceware.org, "H.J. Lu" , Florian Weimer Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-q2/txt/msg00006.txt.bz2 > I would like to propose the addition of a new dynamic tag to the gABI: > > #define DT_GNU_GOT_PLT_END 0x60000100 > > This tag would have two effects: > > * Its presence in the dynamic section would indicate that the > .got.plt section is on its own in a page aligned region of > memory. > > IE no other sections overlap the pages used by the .got.plt, and > the section has been padded so that it ends on a page alignment > boundary. > > * The value of the tag would give the address of the first > byte beyond the end of the .got.plt. > > This means that the size of the .got.plt can be computed by > subtracting the value of the DT_PLTGOT tag from the DT_GNU_GOT_PLT_END > tag. > > The practical use of this tag is to allow the dynamic linker to > isolate the .got.plt section by changing the permissions on the pages > that it occupies. First: If you're proposing this for the gABI, you should drop the "GNU_" from the name. Or are you really proposing this just for the Gnu ABI? Second: Spelling. If the other related tag is DT_PLTGOT, let's spell this one similarly -- DT_PLTGOT_END. Third: Adding an "end of section" address is unusual for the dynamic table. You've been quite explicit to say "the address of the first byte beyond the end of the .got.plt", but it's actually much less error prone to give the size of the section rather than its ending address. You could have DT_PLTGOTSZ, which would parallel other dynamic tags. Fourth: Isn't the size of .got.plt inferrable from DT_PLTRELSZ? Divide that by the size of each relocation (DT_PLTREL == DT_REL ? DT_RELENT : DT_RELAENT), then multiply by the size of the PLTGOT entry (4 or 8), then add the three reserved entries. There's a one-to-one relationship between the PLT and the PLTGOT, and every PLTGOT entry must have a relocation. Fifth: If all you're trying to say is "the .got.plt section is isolated on its own pages", couldn't you just use one of the DT_FLAGS or DT_FLAGS_1? Letting the presence of an END or SZ entry signal this condition is a bit risky -- what if someone decides they'd like to record the size of .got.plt even when it's not isolated on its own pages? -cary