* Re: GDB 6.0 Branch and ARM Multithreading Support
2003-09-05 13:33 GDB 6.0 Branch and ARM Multithreading Support Chris.Pedley
@ 2003-09-05 13:39 ` Daniel Jacobowitz
0 siblings, 0 replies; 4+ messages in thread
From: Daniel Jacobowitz @ 2003-09-05 13:39 UTC (permalink / raw)
To: Chris.Pedley; +Cc: gdb
[-- 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];
^ permalink raw reply [flat|nested] 4+ messages in thread