Re: [RFC] remote-mips.c: Fix bit rot associated with the inferior's state

[Pedro Alves <pedro@codesourcery.com>]

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