This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
qXfer:exec-file:read and non multiprocess target
- From: Philippe Waroquiers <philippe dot waroquiers at skynet dot be>
- To: gdb-patches at sourceware dot org
- Date: Sat, 02 May 2015 11:48:38 +0200
- Subject: qXfer:exec-file:read and non multiprocess target
- Authentication-results: sourceware.org; auth=none
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