Re: Ensure correct symbol-file when attaching to a (remote) process

Re: Ensure correct symbol-file when attaching to a (remote) process

[Pedro Alves]

(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

Re: Ensure correct symbol-file when attaching to a (remote) process

[Pedro Alves]

Blah, wrong list.  Please ignore this copy...

-- 
Pedro Alves