public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: Chris.Pedley@arm.com
Cc: gdb@sources.redhat.com
Subject: Re: GDB 6.0 Branch and ARM Multithreading Support
Date: Fri, 05 Sep 2003 13:39:00 -0000	[thread overview]
Message-ID: <20030905133930.GA23437@nevyn.them.org> (raw)
In-Reply-To: <OF51472554.F81ED3E5-ON80256D98.004984AC-80256D98.004A676B@cambridge.arm.com>

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

On Fri, Sep 05, 2003 at 02:32:41PM +0100, Chris.Pedley@arm.com wrote:
> 
> On 01/09/2003 17:25:01 gdb-owner wrote:
> >On Mon, Sep 01, 2003 at 11:31:36AM +0100, Chris.Pedley@arm.com wrote:
> >> Hi,
> >>
> >> I've cross compiled the GDB 6.0 branch for ARM Linux (host=arm-linux
> >> target=arm-linux build=i686-linux) and can't get it to debug a
> >> multithreaded program.  Attempting to debug a program that creates a
> thread
> >> results in:
> >>
> >> Program received signal SIG32, Real-time event 32.
> >> 0x0000f2c0 in __sigsuspend (set=0xbffffc9c)
> >> ...
> >>
> >> I've linked the program statically against unstripped libraries as I am
> >> aware that people have had trouble debugging multithreaded applications
> >> using a stripped pthread library.
> >>
> >> Any suggestions as to what is wrong?
> >
> >Does it display any messages about loading libthread_db?  Does it
> >successfully map the library?
> 
> I don't get any messages about loading libthread_db, the only worrying
> message is GDB starts up with:
> "Symbol `PC' has different size in shared object, consider re-linking"
> 
> The test application presumably doesn't need to map libthread_db because
> its linked statically?  cat /proc/<gdb pid>/maps includes:

             ^^^^^^^^^^

You didn't mention that :)  It doesn't work.  I have a patch which
works around the problem but it's quite hideous - attached, but I'm not
going to submit it.  I couldn't find a good way to fix the problem
without either breaking core files, or rewriting the target stack.

> >I tested native thread debugging on ARM recently (~ week ago) and it
> >worked.  If you are using glibc 2.3.2 you will need the patch I sent
> >to this list and libc-alpha a week or two ago.
> 
> The library I'm building against, and in my ARM Linux filesystem are both
> glibc 2.3.  Does this need patching?

I don't know.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

[-- Attachment #2: gdb-5.2.1-thread-static.patch --]
[-- Type: text/plain, Size: 5061 bytes --]

Not yet submitted upstream.  This requires some serious thinking about. 
If the target stack worked in any logical way, this wouldn't be necessary...
ending up with roughly:
  thread_stratum: thread-db (silent reference to lin-lwp)
  core_stratum: corelow
  exec_stratum: exec
  dummy_stratum: dummy
just makes no sense.

This patch fixes debugging threaded applications which are statically linked
without breaking debugging threaded core files.  It also fixes the PIDs in
generate-core-file'd corefiles.  Mostly.

diff -x '*~' -ur o/gdb-5.2.debian90.cvs20021120/gdb/corelow.c gdb-5.2.debian90.cvs20021120/gdb/corelow.c
--- o/gdb-5.2.debian90.cvs20021120/gdb/corelow.c	2002-09-18 13:23:15.000000000 -0400
+++ gdb-5.2.debian90.cvs20021120/gdb/corelow.c	2002-12-03 14:03:32.000000000 -0500
@@ -350,7 +350,7 @@
   bfd_map_over_sections (core_bfd, add_to_thread_list,
 			 bfd_get_section_by_name (core_bfd, ".reg"));
 
-  if (ontop)
+  if (ontop || 1)
     {
       /* Fetch all registers from core file.  */
       target_fetch_registers (-1);
diff -x '*~' -ur o/gdb-5.2.debian90.cvs20021120/gdb/target.c gdb-5.2.debian90.cvs20021120/gdb/target.c
--- o/gdb-5.2.debian90.cvs20021120/gdb/target.c	2002-09-18 13:23:22.000000000 -0400
+++ gdb-5.2.debian90.cvs20021120/gdb/target.c	2002-12-03 14:06:07.000000000 -0500
@@ -1589,6 +1589,7 @@
   dummy_target.to_find_memory_regions = dummy_find_memory_regions;
   dummy_target.to_make_corefile_notes = dummy_make_corefile_notes;
   dummy_target.to_magic = OPS_MAGIC;
+  cleanup_target (&dummy_target);
 }
 \f
 
--- gdb-5.3.20030606/gdb/thread-db.c.orig	2003-06-08 11:54:59.000000000 -0400
+++ gdb-5.3.20030606/gdb/thread-db.c	2003-06-08 11:55:05.000000000 -0400
@@ -59,6 +59,31 @@ static void (*target_new_objfile_chain) 
 /* Non-zero if we're using this module's target vector.  */
 static int using_thread_db;
 
+/* Macros to pass an event to the next target if we should not be handling it
+   here in the thread_stratum.  */
+#define FIND_NEXT_TARGET(METHOD_NAME)			\
+  struct target_ops *next_target = &thread_db_ops;	\
+  while (1)						\
+    {							\
+      next_target = find_target_beneath (next_target);	\
+      if (next_target->METHOD_NAME != NULL)		\
+	break;						\
+    }
+
+#define MAYBE_HAND_DOWN(METHOD_NAME,ARGS)		\
+  if (proc_handle.pid == 0)				\
+    {							\
+      FIND_NEXT_TARGET (METHOD_NAME);			\
+      (*next_target->METHOD_NAME) ARGS;			\
+      return;						\
+    }
+#define MAYBE_HAND_DOWN_RETURN(METHOD_NAME,ARGS)	\
+  if (proc_handle.pid == 0)				\
+    {							\
+      FIND_NEXT_TARGET (METHOD_NAME);			\
+      return (*next_target->METHOD_NAME) ARGS;		\
+    }
+
 /* Non-zero if we have to keep this module's target vector active
    across re-runs.  */
 static int keep_thread_db;
@@ -587,9 +612,7 @@ thread_db_new_objfile (struct objfile *o
 {
   td_err_e err;
 
-  /* Don't attempt to use thread_db on targets which can not run
-     (core files).  */
-  if (objfile == NULL || !target_has_execution)
+  if (objfile == NULL)
     {
       /* All symbols have been discarded.  If the thread_db target is
          active, deactivate it now.  */
@@ -613,7 +636,10 @@ thread_db_new_objfile (struct objfile *o
   /* Initialize the structure that identifies the child process.  Note
      that at this point there is no guarantee that we actually have a
      child process.  */
-  proc_handle.pid = GET_PID (inferior_ptid);
+  if (target_has_execution)
+    proc_handle.pid = GET_PID (inferior_ptid);
+  else
+    proc_handle.pid = 0;
 
   /* Now attempt to open a connection to the thread library.  */
   err = td_ta_new_p (&proc_handle, &thread_agent);
@@ -881,6 +907,9 @@ thread_db_xfer_memory (CORE_ADDR memaddr
   struct cleanup *old_chain = save_inferior_ptid ();
   int xfer;
 
+  MAYBE_HAND_DOWN_RETURN (to_xfer_memory, (memaddr, myaddr, len, write,
+					   attrib, target));
+
   if (is_thread (inferior_ptid))
     {
       /* FIXME: This seems to be necessary to make sure breakpoints
@@ -907,6 +936,10 @@ thread_db_fetch_registers (int regno)
   gdb_prfpregset_t fpregset;
   td_err_e err;
 
+  MAYBE_HAND_DOWN (to_fetch_registers, (regno));
+
+  MAYBE_HAND_DOWN (to_store_registers, (regno));
+
   if (!is_thread (inferior_ptid))
     {
       /* Pass the request to the target beneath us.  */
@@ -1040,6 +1073,8 @@ thread_db_thread_alive (ptid_t ptid)
   td_thrhandle_t th;
   td_err_e err;
 
+  MAYBE_HAND_DOWN_RETURN (to_thread_alive, (ptid));
+
   if (is_thread (ptid))
     {
       struct thread_info *thread_info;
@@ -1104,6 +1139,8 @@ thread_db_find_new_threads (void)
 {
   td_err_e err;
 
+  MAYBE_HAND_DOWN (to_find_new_threads, ());
+
   /* Iterate over all user-space threads to discover new threads.  */
   err = td_ta_thr_iter_p (thread_agent, find_new_threads_callback, NULL,
 			  TD_THR_ANY_STATE, TD_THR_LOWEST_PRIORITY,
@@ -1115,6 +1152,8 @@ thread_db_find_new_threads (void)
 static char *
 thread_db_pid_to_str (ptid_t ptid)
 {
+  MAYBE_HAND_DOWN_RETURN (to_pid_to_str, (ptid));
+
   if (is_thread (ptid))
     {
       static char buf[64];

  reply	other threads:[~2003-09-05 13:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-05 13:33 Chris.Pedley
2003-09-05 13:39 ` Daniel Jacobowitz [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-09-01 10:31 Chris.Pedley
2003-09-01 16:25 ` Daniel Jacobowitz

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=20030905133930.GA23437@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=Chris.Pedley@arm.com \
    --cc=gdb@sources.redhat.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).