This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
target_find_description question
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: drow at false dot org
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 3 Sep 2008 01:47:56 +0200 (CEST)
- Subject: target_find_description question
Hi Dan,
in testing the Cell debugger, I came across the question how to handle
target_find_description for native (inf-ptrace) targets. As I understand
it, the idea is to determine the target description *before* any access
to target registers happens. However, for inf-ptrace targets this is
not the case: inf_ptrace_create_inferior calls fork_inferior, which
call the inf_ptrace_him callback, which calls startup_inferior.
That latter function now calls wait_for_inferior. This does not only
do a target_wait, however, but does the full handle_inferior_event
processing -- which at the very least reads the PC register (for
decr_pc_after_break processing and to set stop_pc). This happens
*before* target_find_description is called (from post_create_inferior).
Now, this ususally doesn't matter much, because the PC tends not to
be changed by target descriptions -- and even if it were, this would
just mean we got (and igored) and invalid value for stop_pc on startup.
However, with the multi-arch debugger, this can actually mean that
the ppc_linux_fetch_inferior_registers routine gets called with a
regcache architecture that is not even PowerPC! This is a problem
in that subroutines of ppc_linux_fetch_inferior_registers will do
a gdbarch_tdep () on that architecture and blindly access it as if
it were the PowerPC version, causing random memory accesses.
In fact, I guess you could even construct cases where that happens with
today's mainline GDB when built with secondary target support: suppose
you debug some non-PowerPC remote target, detach from it (leaving
current_gdbarch pointing to that other architecture), and then attach
to a native PowerPC process in the same GDB session.
Right now I've solved the invalid memory access by a simple check
in ppc_linux_fetch_inferior_registers whether the regcache is actually
for PowerPC, and just silently returning if it isn't.
But it seems a proper fix should be rather to call target_find_description
earlier, indeed before any register access happens. Unfortunately this
is a bit awkward as it would mean that either startup_inferior can no
longer just call wait_for_inferior, or else that there would need to
be special handling for this case in wait_for_inferior ...
Do you have any suggestions how best to handle this?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com