This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

qXfer:exec-file:read and non multiprocess target


I am busy adding qXfer:exec-file:read  to the Valgrind gdbserver.

Even if Valgrind reports it supports qXfer:exec-file, 
GDB does not query it.
This is due to the fact that GDB does not query the exec-file when 
the pid is a fake pid, which is the case for Valgrind, as the target
command to use is:
   target remote | vgdb

The following change in remote.c ensures GDB queries the
remote exec-file:
1561,1562c1561,1562
<   if (try_open_exec && !fake_pid_p && get_exec_file (0) == NULL)
<     exec_file_locate_attach (pid, 1);
---
>   if (try_open_exec && get_exec_file (0) == NULL)
>     exec_file_locate_attach (fake_pid_p ? 0 : pid, 1);

With that change, GDB can use a Valgrind target without having
to specify the exec file.
The idea is that when the stub gets a pid 0 in this request, it
replies with the exec file of the current process.

I have not yet investigated a remaining problem:

if the same GDB does first a
  target remote|vgdb 
and gets as exec-file   firstexecfile,
then after the first target has terminated,
a second target remote|vgdb for another
process does not re-query the exec file : GDB uses the
first exec file, even if the second target has another file.

Feedback about allowing the exec-file of a fake pid to be queried ?

Philippe



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]