From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58647 invoked by alias); 23 Jun 2018 04:49:05 -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 58466 invoked by uid 89); 23 Jun 2018 04:48:50 -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=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 spammy=Third, Hx-languages-length:1685 X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 23 Jun 2018 04:48:24 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4B59F401C96B; Sat, 23 Jun 2018 04:48:22 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-116-32.ams2.redhat.com [10.36.116.32]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7790E2166BB2; Sat, 23 Jun 2018 04:48:21 +0000 (UTC) Subject: Re: RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END To: Cary Coutant , Nick Clifton Cc: gnu-gabi@sourceware.org, "H.J. Lu" References: <87sh5hadd6.fsf@redhat.com> <83d583d0-884e-4208-436e-5b25cbb6ce5a@redhat.com> From: Florian Weimer Message-ID: Date: Mon, 01 Jan 2018 00:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Sat, 23 Jun 2018 04:48:22 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Sat, 23 Jun 2018 04:48:22 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'fweimer@redhat.com' RCPT:'' X-IsSubscribed: yes X-SW-Source: 2018-q2/txt/msg00008.txt.bz2 On 06/22/2018 11:28 PM, Cary Coutant wrote: > 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. With the size, it's also possible to express that the section ends at the top of the address space. (Although this doesn't really matter in practice.) > 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. The PLT count wouldn't include the padding at the end of the section, so it doesn't confer the required information. > 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? Well, isn't this a problem no matter what we specify? That someone might provide incorrect information? If we use a number, at least disagreement about the run-time page size isn't a source of potential issues. Thanks, Florian