This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Ensure correct symbol-file when attaching to a (remote) process
- From: Raphael Zulliger <zulliger at indel dot ch>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb at sourceware dot org
- Date: Tue, 29 Jan 2013 04:18:11 +0100
- 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>
(I apologize: I've replied to this mail some weeks ago - but forgot to
CC to the list. I therefore resend this email)
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.
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? Could such a protocol extension, and
the according build-id comparison check make it into GDB?