This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] remote-mips.c: Fix bit rot associated with the inferior's state
On Thursday 04 March 2010 23:33:19, Kevin Buettner wrote:
> Long term, I'm not sure what to do about this. Short term, I'd like
> to leave it as shown in the patch below - which is the same as the
> earlier patch that you've looked at.
That's fine.
>
> I tried setting attach_flag in the inferior and making mips_kill throw
> an error, but that messes up gdb.base/opaque.exp. Here's the relevant
> bit from the log file:
>
> (gdb) PASS: gdb.base/opaque.exp: ptype on opaque struct tagname (statically)
> dir
> Reinitialize source path to empty? (y or n) y
> Source directories searched: $cdir:$cwd
> (gdb) dir /ironwood1/sourceware-remote-mips/mips64vrel-elf/bld32/../../src/gdb/testsuite/gdb.base
> Source directories searched: /ironwood1/sourceware-remote-mips/mips64vrel-elf/bld32/../../src/gdb/testsuite/gdb.base:$cdir:$cwd
> (gdb) kill
> Kill the program being debugged? (y or n) y
> Can't kill this target.
> Use `detach' to disconnect from the target board's monitor.
> (gdb) file /mesquite2/sourceware-remote-mips/mips64vrel-elf/bld32/gdb/testsuite/gdb.base/opaque
> A program is being debugged already.
> Are you sure you want to change the file? (y or n) ERROR: couldn't load /mesquite2/sourceware-remote-mips/mips64vrel-elf/bld32/gdb/testsuite/gdb.base/opaque into /mesquite2/sourceware-remote-mips/mips64vrel-elf/bld32/gdb/testsuite/../../gdb/gdb (timed out).
> delete breakpoints
> Please answer y or n.
> A program is being debugged already.
> Are you sure you want to change the file? (y or n) ERROR: Delete all breakpoints in delete_breakpoints (timeout)
> break main
> Please answer y or n.
> A program is being debugged already.
> Are you sure you want to change the file? (y or n) UNRESOLVED: gdb.base/opaque.exp: setting breakpoint at main (timeout)
> ERROR: cannot run to breakpoint at main
>
I'd call it a test bug to be trying to kill on such
configuration, but then again, it's really strange that
there's no defined way to kill/reset the board. But really,
I'm super fine with what you have, as long as it works for you.
I'm surprised to find there's still use for this target (and
I confess that it was on my TODO list to garbage collect it);
AFAIK, modern MIPS debugging nowadays either goes either
through the remote protocol, or through MDI (remote-mdi.c).
> Below is my current patch.
>
> * remote-mips.c (gdbthread.h): Include.
> (remote_mips_ptid): Declare.
> (mips_error): Only mourn the inferior when inferior_ptid is non-null.
> (common_open): Set inferior_ptid, add it as an inferior, and
> as a thread too. Delete FIXME comment regarding start_remote().
> (mips_close): Invoke generic_mourn_inferior().
> (mips_kill): Make sure that target_mourn_inferior is invoked.
> (mips_mourn_inferior): Don't invoke generic_mourn_inferior, as
> it's now invoked from mips_close().
> (mips_load): Don't null out inferior_ptid. Don't call
> clear_symtab_users().
> (mips_thread_alive, mips_pid_to_str): New functions.
> (_initialize_remote_mips): Initialize remote_mips_ptid. Initialize
> to_thread_alive and to_pid_to_str operations.
Looks good to me. Thanks.
--
Pedro Alves