Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Subject: remote-mips.c, always a thread
Date: Mon, 18 Aug 2008 12:29:00 -0000	[thread overview]
Message-ID: <200808181329.28252.pedro@codesourcery.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1271 bytes --]

Hi,

This patch makes the remote mips targets (mips,pmon,ddb,lsi) register a
thread in GDB's thread list.

While going through the file, I noticed a couple of other issues:

- 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.

- 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.

This hasn't been tested at all, but, does it looks reasonable?

-- 
Pedro Alves

[-- Attachment #2: remote_mips.diff --]
[-- Type: text/x-diff, Size: 3096 bytes --]

2008-08-18  Pedro Alves  <pedro@codesourcery.com>

	* remote-mips.c: Include "gdbthread.h".
	(remote_mips_ptid): New.
	(common_open): Set inferior_ptid to remote_mips_ptid and add it as
	a thread to GDB's thread list.
	(mips_close): Delete remote_mips_ptid from GDB's thread list.
	(mips_create_inferior): Remove FIXME note.
	(mips_load): Don't delete symtab users, or reset inferior_ptid.
	(_initialize_remote_mips): Initialize remote_mips_ptid.

---
 gdb/remote-mips.c |   27 +++++++++++++++------------
 1 file changed, 15 insertions(+), 12 deletions(-)

Index: src/gdb/remote-mips.c
===================================================================
--- src.orig/gdb/remote-mips.c	2008-08-17 23:28:19.000000000 +0100
+++ src/gdb/remote-mips.c	2008-08-18 13:09:40.000000000 +0100
@@ -35,6 +35,7 @@
 #include "regcache.h"
 #include <ctype.h>
 #include "mips-tdep.h"
+#include "gdbthread.h"
 \f
 
 /* Breakpoint types.  Values 0, 1, and 2 must agree with the watch
@@ -450,6 +451,11 @@ struct lsi_error lsi_error_table[] =
    of warnings returned by PMON when hardware breakpoints are used.  */
 static int monitor_warnings;
 
+/* This is the ptid we use while we're connected to the remote.  Its
+   value is arbitrary, as the remote-sim target don't have a notion or
+   processes or threads, but we need something non-null to place in
+   inferior_ptid.  */
+static ptid_t remote_mips_ptid;
 
 static void
 close_ports (void)
@@ -1577,6 +1583,9 @@ device is attached to the target board (
   /* Try to figure out the processor model if possible.  */
   deprecated_mips_set_processor_regs_hack ();
 
+  inferior_ptid = remote_mips_ptid;
+  add_thread_silent (remote_mips_ptid);
+
   /* This is really the job of start_remote however, that makes an
      assumption that the target is about to print out a status message
      of some sort.  That doesn't happen here (in fact, it may not be
@@ -1648,6 +1657,8 @@ mips_close (int quitting)
 
       close_ports ();
     }
+
+  delete_thread_silent (remote_mips_ptid);
 }
 
 /* Detach from the remote board.  */
@@ -2208,8 +2219,6 @@ Can't pass arguments to remote MIPS boar
 
   init_wait_for_inferior ();
 
-  /* FIXME: Should we set inferior_ptid here?  */
-
   write_pc (entry_pt);
 }
 
@@ -3288,16 +3297,6 @@ mips_load (char *file, int from_tty)
     }
   if (exec_bfd)
     write_pc (bfd_get_start_address (exec_bfd));
-
-  inferior_ptid = null_ptid;	/* No process now */
-
-/* This is necessary because many things were based on the PC at the time that
-   we attached to the monitor, which is no longer valid now that we have loaded
-   new code (and just changed the PC).  Another way to do this might be to call
-   normal_stop, except that the stack may not be valid, and things would get
-   horribly confused... */
-
-  clear_symtab_users ();
 }
 
 
@@ -3450,4 +3449,8 @@ Use \"on\" to enable the masking and \"o
 			   NULL,
 			   NULL, /* FIXME: i18n: */
 			   &setlist, &showlist);
+
+  /* Yes, 42000 is arbitrary.  The only sense out of it, is that it
+     isn't 0.  */
+  remote_mips_ptid = ptid_build (42000, 0, 42000);
 }

             reply	other threads:[~2008-08-18 12:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-18 12:29 Pedro Alves [this message]
2008-08-18 13:07 ` Pedro Alves
2008-08-19 19:38   ` [02/02] remote-mips.c, always a thread (take 2) Pedro Alves
2008-08-19 19:38   ` [01/02] " Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200808181329.28252.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox