From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8517 invoked by alias); 1 Feb 2013 21:32:16 -0000 Received: (qmail 8509 invoked by uid 22791); 1 Feb 2013 21:32:16 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from na3sys009aog101.obsmtp.com (HELO na3sys009aog101.obsmtp.com) (74.125.149.67) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 01 Feb 2013 21:32:09 +0000 Received: from mx10.qnx.com ([209.226.137.110]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKUQw0PweNe75HL4KfNo2CQ5Yrxw4McBLD@postini.com; Fri, 01 Feb 2013 13:32:08 PST Received: by mx10.qnx.com (Postfix, from userid 500) id 32E5D21160; Fri, 1 Feb 2013 16:31:43 -0500 (EST) Received: from exhts.ott.qnx.com (exch2 [10.222.2.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx10.qnx.com (Postfix) with ESMTPS id 01C5720E5D; Fri, 1 Feb 2013 16:31:43 -0500 (EST) Received: from [10.222.96.215] (10.222.2.5) by exch2.ott.qnx.com (10.222.2.136) with Microsoft SMTP Server id 14.2.318.4; Fri, 1 Feb 2013 16:31:42 -0500 Message-ID: <510C343D.8020500@qnx.com> Date: Fri, 01 Feb 2013 21:32:00 -0000 From: Aleksandar Ristovski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 Newsgroups: gmane.comp.gdb.patches To: Jan Kratochvil CC: "gdb-patches@sourceware.org" Subject: Re: [patch] validate binary before use References: <50DCAA5C.3000301@qnx.com> <20121227205924.GA5109@host2.jankratochvil.net> <50DCB787.6020601@qnx.com> <20121227211328.GA5739@host2.jankratochvil.net> <50DCBBD1.7000707@qnx.com> <5107F591.304@qnx.com> <20130130191646.GA1034@host2.jankratochvil.net> <510A7E4B.4040608@qnx.com> <20130201030610.GA12800@host2.jankratochvil.net> <510BD1BF.2050209@qnx.com> <20130201200418.GA18674@host2.jankratochvil.net> In-Reply-To: <20130201200418.GA18674@host2.jankratochvil.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2013-02/txt/msg00037.txt.bz2 On 13-02-01 03:04 PM, Jan Kratochvil wrote: > On Fri, 01 Feb 2013 15:31:27 +0100, Aleksandar Ristovski wrote: >> On 13-01-31 10:06 PM, Jan Kratochvil wrote: >>> This behavior is correct. Changing it would break all the tools around. >> >> >> If you say so. IMO it is less than ideal, it should specify l_addr >> as expected and make prelink transparent. Like this, it special >> cases meaning of this field, which is common and across many systems >> happens to always have the same meaning (except when 'successful' >> prelinking happens). >> > > FYI on gdbserver/linux-low.c get_phdr_phnum_from_proc_auxv finds PHDR_MEMADDR > which is the absolute L_ADDR form you ask for. > > Just solib-svr4.c tries to be (is it?) cross-OS compatible so it does not have > this PHDR_MEMADDR value available. To avoid any misunderstanding: I am not emotional about this topic at all. Take what follows as a light-weight hallway conversation over a coffee: I will not claim familiarity with how linux works, but auxv typically has information for the executable only, not the shared objects (i.e. auxv is the "connecting link" between process loader and dynamic linker - interpreter). For shared objects, however, this can not be used because the information is not there. Dynamic linker does not add anything to auxv nor does auxv have entries for e.g. load base of any of the shared objects. To be clear: I am very familiar with how this works on Neutrino and the preceding and following claims come from that and *not* from gnu/ld familiarity. If it's different on gnu/linux, let me know. Using auxv is fairly os-agnostic as long as an os is svr4-like. solib-svr4.c uses auxv via target_auxv_search, nothing wrong with that. But again, this applies to exe only. Auxv does not have any information about arbitrary shared objects executable links against - that is entirely ld's business and not process loader's. Therefore, the only clue for deterministic and straight forward relocation calculus for a tool like gdb is l_addr from the link map. If gnu ld is not setting it up when "successful prelink" happens it is making a mistake: 0 load base may be legitimate and true in some cases on some systems. Furhter, it unnecessary introduces this difference when it would probably change very little (nothing?) if it set it up correctly to what the load base really is, just as it does for "unsuccessful" prelinks or non-prelinked objects.