* Re: Ensure correct symbol-file when attaching to a (remote) process
[not found] ` <50EA78FB.3040609@indel.ch>
@ 2013-01-14 18:52 ` Pedro Alves
2013-01-14 18:56 ` Pedro Alves
0 siblings, 1 reply; 2+ messages in thread
From: Pedro Alves @ 2013-01-14 18:52 UTC (permalink / raw)
To: Raphael Zulliger, GDB Patches
(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
^ permalink raw reply [flat|nested] 2+ messages in thread