target_find_description question

["Ulrich Weigand" <uweigand@de.ibm.com>]

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