From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22653 invoked by alias); 4 Apr 2013 02:03:58 -0000 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 Received: (qmail 22641 invoked by uid 89); 4 Apr 2013 02:03:58 -0000 X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.1 Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 04 Apr 2013 02:03:55 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UNZXF-0003bL-KF for gdb-patches@sourceware.org; Thu, 04 Apr 2013 04:04:17 +0200 Received: from cpebc1401279e63-cmbc1401279e60.cpe.net.cable.rogers.com ([99.224.111.91]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 04 Apr 2013 04:04:17 +0200 Received: from aristovski by cpebc1401279e63-cmbc1401279e60.cpe.net.cable.rogers.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 04 Apr 2013 04:04:17 +0200 To: gdb-patches@sourceware.org From: Aleksandar Ristovski Subject: Re: [patch] validate binary before use Date: Thu, 04 Apr 2013 11:07:00 -0000 Message-ID: <515CDF7F.5020403@qnx.com> References: <5107F591.304@qnx.com> <20130131063518.GA3027@host2.jankratochvil.net> <510A7EB0.90702@qnx.com> <51278A2A.9000802@qnx.com> <512E42D1.3040101@qnx.com> <514C58B2.6090701@qnx.com> <20130328183727.GA14798@host2.jankratochvil.net> <515B0632.1040502@qnx.com> <20130402165306.GA9479@host2.jankratochvil.net> <515B12D1.7050505@qnx.com> <20130403180917.GA6102@host2.jankratochvil.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "gdb-patches@sourceware.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 In-Reply-To: <20130403180917.GA6102@host2.jankratochvil.net> X-SW-Source: 2013-04/txt/msg00095.txt.bz2 Actually, as I think about this more, we can not use section from possibly unrelated bfd to read build-id in native debugging case. At a minimum, we can not store such build-id as abfd may not even relate to what's in target's memory. The chunk of code that is in svr4_relocate_section_addresses in the latest version of the patch needs to go back to svr4_validate, and not store build-id. Ideally, however, build id would be read from target memory phdrs, not from bfd. Main complication, of course, is that due to missing load base for a shared object, this becomes target os specific. On Neutrino, it is straight forward, but on gnu it requires parsing smaps. So, I'm thinking that linux-nat should be taught to return TARGET_OBJECT_LIBRARIES_SVR4, and also augument gdbserver to return load base. i.e. gdbserver would return, in addition to what it already does, a mandatory attribute "load_base". If a native implementation does not support TARGET_OBJECT_LIBRARIES_SVR4, build-id is not checked. Thoughts?