Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* target_find_description question
@ 2008-09-02 23:49 Ulrich Weigand
  2008-09-04 12:12 ` Daniel Jacobowitz
  0 siblings, 1 reply; 11+ messages in thread
From: Ulrich Weigand @ 2008-09-02 23:49 UTC (permalink / raw)
  To: drow; +Cc: gdb-patches

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


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2008-09-11 16:13 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-09-02 23:49 target_find_description question Ulrich Weigand
2008-09-04 12:12 ` Daniel Jacobowitz
2008-09-04 19:17   ` Ulrich Weigand
2008-09-04 21:52     ` Daniel Jacobowitz
2008-09-04 22:12       ` Pedro Alves
2008-09-04 22:27         ` Pedro Alves
2008-09-05  0:00           ` [patch, rfc] " Ulrich Weigand
2008-09-05  2:40             ` Daniel Jacobowitz
2008-09-05 13:11             ` Pedro Alves
2008-09-06  1:55             ` Joel Brobecker
2008-09-11 16:13             ` Ulrich Weigand

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox