On Monday 18 August 2008 14:07:34, Pedro Alves wrote:

> I forgot to add a new target_thread_alive function, otherwise,
> info threads gets rid of the thread I just added.

And here's a new patch that fixes that.  Here are the same
notes I posted yesterday:

- nowhere in the file was inferior_ptid set, but there
  were places where it was being set to null_ptid (you can
  see one such place in the patch).

- mips_load was clearing inferior_ptid, and calling clear_symtab_users.  I 
  notice that inferior_ptid is being cleared after a load command, but that
  is wrong, I believe.  See this change of Jim's to monitor.c, that removed
  this clearing from the monitor target:
   http://sourceware.org/ml/gdb/2001-09/msg00125.html

  I'm applying the exact same reasoning and change here.

  If this patch goes in without the previous patch, issuing "run" and the
  user answering yes to "The program being debugged has been
  started already.  Start it from the beginning?" ends up calling target_kill
  which sends the remote a break.  With the previous patch installed,
  The user can use ctrl-c at the terminal to interrupt the remote, and
  target_kill will do nothing, just like monitor.c does (which seems to
  share some history with remote-mips.c).

- There's a FIXME in mips_create_inferior, wondering if it should set
  inferior_ptid there.  I believe the answer is negative.  When you get to
  mips_create_inferior, the target is already with execution -- you have it
  since target_open.  The "run" command against this target merelly sets
  the PC to the entry points, and proceeds.  The user could have also
  just "target mips ..." followed by "continue".  See Jim's email above, his
  very nice explanation makes it clearer.

I've checked that this at least compiles.  Keep in mind that there is no
current configuration using this file (which I had noticed before).

I would definitelly not opposse GCing this file instead.

-- 
Pedro Alves