From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29056 invoked by alias); 14 Jan 2013 18:52:05 -0000 Received: (qmail 29045 invoked by uid 22791); 14 Jan 2013 18:52:04 -0000 X-SWARE-Spam-Status: No, hits=-7.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 14 Jan 2013 18:51:53 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r0EIpoEL001929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Jan 2013 13:51:50 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r0EIpmKZ009833; Mon, 14 Jan 2013 13:51:49 -0500 Message-ID: <50F453C4.4060502@redhat.com> Date: Mon, 14 Jan 2013 18:52:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Raphael Zulliger , GDB Patches Subject: Re: Ensure correct symbol-file when attaching to a (remote) process References: <50D3FC31.1020103@indel.ch> <20121221161114.GA32638@host2.jankratochvil.net> <201212211917.qBLJH6Il028006@new.toad.com> <50E474E3.7050605@redhat.com> <50EA78FB.3040609@indel.ch> In-Reply-To: <50EA78FB.3040609@indel.ch> Content-Type: text/plain; charset=ISO-8859-1 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-01/txt/msg00280.txt.bz2 (adding back gdb-patches@, which seems to have been removed from CC by mistake). On 01/07/2013 07:27 AM, Raphael Zulliger wrote: > On 01/02/2013 06:56 PM, Pedro Alves wrote: >> A build id check would really be ideal. > I agree. (--build-id is a very interesting feature which I was not > aware of. Thanks for that hint Jan) > > In our scenario, our GDB stub could get that build-id from the > running target: Our embedded systems provides a variable read/write > mechanism accessible by the stub. Moreover, the embedded system > could be made aware of the address of the build-id by introducing > variables around the .note.gnu.build-id section in the linker > script. Assuming the enough sticks around in the binary that goes to the system to have the stub find those variables without relying on GDB, sounds like something that should work. > > Therefore, if the GDB remote serial protocol would offer a way to > "get" that id from the stub and GDB would offer a feature to > compare/check that id, it'd perfectly work for us. AFAIK there are > no "generic" ways of transferring data by the remote serial > protocol, therefore, we'd need to extend it accordingly, right? For getting the build-id blob, it sounds pretty much like something for qXfer:$object:read. You'd just need to define a new (e.g.) "gnu-build-id" $object (there's some mechanics involved, but also examples to follow). > Could such a protocol extension, and the according build-id > comparison check make it into GDB? IMO, yes. For GNU/Linux and other systems, we'd need a build-id per executable/library/module, so it seems like the build-id could/should be reported in the existing qXfer:libraries/qXfer:libraries-svr4 as well. -- Pedro Alves