From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Subject: [RFA/RFC] Fix broken user-thread debugging on x86-solaris
Date: Wed, 12 Mar 2008 17:08:00 -0000 [thread overview]
Message-ID: <20080312170814.GC4433@adacore.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2653 bytes --]
Hello,
While testing GDB on x86-solaris, I noticed that the debugger now prints
a warning during startup:
% ./gdb
[GDB will not be able to debug user-mode threads: ld.so.1: gdb.ref: fatal: relocation error: file /usr/lib/libthread_db.so.1: symbol ps_lgetLDT: referenced symbol not found]
GNU gdb 6.8.50.20080311-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
[...]
The problem was introduced when we killed the TM file, which was
defining the TM_I386SOL2_H macro that a couple of units were actually
using (ugh!).
Basically, the problem on x86-solaris is that, in order to load
libthread_db.so, we need to define ps_lgetLDT or the loading
will fail due to this symbol being undefined. This function is
defined inside sol-thread.c but is conditionalized on TM_I386SOL2_H
being defined:
#ifdef TM_I386SOL2_H
/* Reads the local descriptor table of a LWP. */
ps_err_e
ps_lgetLDT (gdb_ps_prochandle_t ph, lwpid_t lwpid,
struct ssd *pldt)
{
Similarly, a couple of other functions inside procfs.c that
this function uses are conditionalized on the same macro:
proc_get_LDT_entry and procfs_find_LDT_entry. This stuff is
entirely x86-solaris specific, so cannot be enabled on sparc-solaris.
I think the most classical way of fixing this would be to move these
to their own file, such as sol-x86-thread.c. But I'm not sure whether
this is going to be the prefered solution in this case, because
the procfs routines need access to certain fields of a structure
that is not public (struct procinfo).
In this version, I went to the simplest, which is to have configure
define a new macro (HAVE_X86_SOLARIS_USER_THREADS) when on x86-solaris
and the thread_db library is available. I then replaced TM_I386SOL2_H
by the new macro.
If I were to move the 3 functions to their own file, I would have
to create procfs.h to provide an opaque definition of struct procinfo.
I would also add a few accessor routines (to get the pid and the ctl_fd),
and make a few routines such as find_procinfo or proc_get_gregs non-static.
I don't mind doing this work, but I want to make sure others prefer it too.
2008-03-12 Joel Brobecker <brobecker@adacore.com>
* configure.ac (HAVE_X86_SOLARIS_USER_THREADS): Define this macro
if we are building a native x86-solaris debugger that has access
to user-threads.
* configure, config.in: Regenerate.
* sol-thread.c, procfs.c : Use HAVE_X86_SOLARIS_USER_THREADS
in place of TM_I386SOL2_H.
Tested on x86-solaris. No regression.
Opinions?
BTW: We should fix this in the branch as well.
Thanks,
--
Joel
[-- Attachment #2: x86-user-threads.diff --]
[-- Type: text/plain, Size: 3155 bytes --]
Index: configure.ac
===================================================================
--- configure.ac (revision 34930)
+++ configure.ac (working copy)
@@ -1221,6 +1221,11 @@ if test ${build} = ${host} -a ${host} =
[Define if <proc_service.h> on solaris uses int instead of
size_t, and assorted other type changes.])
fi
+ if test "${gdb_host_cpu}" = "i386" ; then
+ AC_DEFINE(HAVE_X86_SOLARIS_USER_THREADS, 1,
+ [Define if the thread layer uses the user-thread debug library
+ on an x86-solaris system])
+ fi
else
AC_MSG_RESULT(no)
fi
Index: configure
===================================================================
--- configure (revision 34930)
+++ configure (working copy)
@@ -22865,6 +22865,13 @@ cat >>confdefs.h <<\_ACEOF
_ACEOF
fi
+ if test "${gdb_host_cpu}" = "i386" ; then
+
+cat >>confdefs.h <<\_ACEOF
+#define HAVE_X86_SOLARIS_USER_THREADS 1
+_ACEOF
+
+ fi
else
echo "$as_me:$LINENO: result: no" >&5
echo "${ECHO_T}no" >&6
Index: config.in
===================================================================
--- config.in (revision 34930)
+++ config.in (working copy)
@@ -482,6 +482,10 @@
/* Define to 1 if `vfork' works. */
#undef HAVE_WORKING_VFORK
+/* Define if the thread layer uses the user-thread debug library on an
+ x86-solaris system */
+#undef HAVE_X86_SOLARIS_USER_THREADS
+
/* Define to 1 if you have the `XML_StopParser' function. */
#undef HAVE_XML_STOPPARSER
Index: sol-thread.c
===================================================================
--- sol-thread.c (revision 34930)
+++ sol-thread.c (working copy)
@@ -1298,7 +1298,7 @@ ps_pdmodel (gdb_ps_prochandle_t ph, int
}
#endif /* PR_MODEL_LP64 */
-#ifdef TM_I386SOL2_H
+#ifdef HAVE_X86_SOLARIS_USER_THREADS
/* Reads the local descriptor table of a LWP. */
@@ -1326,7 +1326,7 @@ ps_lgetLDT (gdb_ps_prochandle_t ph, lwpi
/* LDT not found. */
return PS_ERR;
}
-#endif /* TM_I386SOL2_H */
+#endif /* HAVE_X86_SOLARIS_USER_THREADS */
\f
/* Convert PTID to printable form. */
Index: procfs.c
===================================================================
--- procfs.c (revision 34930)
+++ procfs.c (working copy)
@@ -3028,7 +3028,7 @@ proc_set_watchpoint (procinfo *pi, CORE_
#endif
}
-#ifdef TM_I386SOL2_H /* Is it hokey to use this? */
+#ifdef HAVE_X86_SOLARIS_USER_THREADS
#include <sys/sysi86.h>
@@ -3120,7 +3120,7 @@ proc_get_LDT_entry (procinfo *pi, int ke
#endif
}
-#endif /* TM_I386SOL2_H */
+#endif /* HAVE_X86_SOLARIS_USER_THREADS */
/* =============== END, non-thread part of /proc "MODULE" =============== */
@@ -5549,7 +5549,7 @@ procfs_stopped_by_watchpoint (ptid_t pti
return 0;
}
-#ifdef TM_I386SOL2_H
+#ifdef HAVE_X86_SOLARIS_USER_THREADS
/*
* Function: procfs_find_LDT_entry
*
@@ -5587,7 +5587,7 @@ procfs_find_LDT_entry (ptid_t ptid)
/* Find the matching entry and return it. */
return proc_get_LDT_entry (pi, key);
}
-#endif /* TM_I386SOL2_H */
+#endif /* HAVE_X86_SOLARIS_USER_THREADS */
/*
* Memory Mappings Functions:
next reply other threads:[~2008-03-12 17:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-12 17:08 Joel Brobecker [this message]
2008-03-12 17:22 ` Daniel Jacobowitz
2008-03-12 18:05 ` Joel Brobecker
2008-03-12 18:13 ` Daniel Jacobowitz
2008-03-12 20:08 ` Joel Brobecker
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=20080312170814.GC4433@adacore.com \
--to=brobecker@adacore.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