From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id 496a2efd for ; Fri, 31 Jan 2020 18:01:23 +0000 (UTC) Received: (qmail 17422 invoked by uid 550); 31 Jan 2020 18:01:21 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 16380 invoked from network); 31 Jan 2020 18:01:21 -0000 Date: Fri, 31 Jan 2020 13:01:09 -0500 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200131180109.GJ1663@brightrain.aerifal.cx> References: <20200129191946.GI2020@voyager> <20200130170249.GK2020@voyager> <20200131164009.GI1663@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: Re: [musl] Static linking is broken after creation of DT_TEXTREL segment On Fri, Jan 31, 2020 at 08:51:05PM +0300, Андрей Аладьев wrote: > > Moreover, adding such a thing is not desirable because it adds a > linear-search of an array of load segments to each relocation > > I think it is possible to make this search O(log n). This would help if n were large, but in practice it's very small (2-3 or maybe 4) and the cost is just the code path overhead, which gets worse if you do that, not the largeness of n. > for (j=0; v-p->loadmap->segs[j].p_vaddr >= p->loadmap->segs[j].p_memsz; > j++); > > This code takes first segment that can handle address. It looks possible to > create modified list of virtual segments, that won't overlap and make a > binary search. They're non-overlapping anyway but not necessarily sorted, and can't be simultaneously sorted by addr and p_vaddr since the orders will differ. > > This is not a reasonable tradeoff and it's why I proposed the "hull" > approach > > It may not be safe from maintainability perspective. Library will be > changed, everybody will forget what part of code was protected by external > validation and it will provide unexpected behaviour. Please consider double > validation approach: You're really not making sense here. What does "protected by external validation" mean? There is presently nothing being "protected" here; the discussion is just about more informative errors. If this is used as a boundary for some sort of safety at some point in the future (as mentioned before, the benefit of this is probably limited to ldd and thus not very useful) then it will be done according to constraints needed to achieve that. > external validation in production and debug only mode > with loadmap like validation. We do not have separate "production" and "debug" modes. This kind of thing (combinatoric build-time options) is what lacks maintainability. Rich