From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: Ulrich Weigand <uweigand@de.ibm.com>
Subject: AIX, always a thread, experimental patch
Date: Tue, 19 Aug 2008 17:08:00 -0000 [thread overview]
Message-ID: <200808191808.43011.pedro@codesourcery.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2401 bytes --]
Hi,
I've given another look at aix-thread.c, in an effort to make it work with the
always-a-thread changes, and came up with the attached patch. It is obviously
not finished, but it should point at the direction we should take (I hope).
I still can't tell if rs6000_wait can ever return a ptid different from
pid_to_ptid(main_process_pid), (or -1). I assume that GDB is already assuming
that libpthdebug.a is always available, as IBM's docs claim AIX can operate
under an M:N model (aix-threads.c seems to manage that), but there isn't
anything in rs6000-nat.c managing lwps. I hope this is not relying on
handle_inferior_event:new_thread_event when debugging a thread app, and
libpthdebug.a isn't available for some reason or for debugging lwp based
apps that don't use pthreads. ptids representing the lwps of the same
inferior should be of the form (pid,lwpid,0), not (lwpid,0,0), as it
would happen if rs6000-nat.c relied on new_thread_event.
As I mentioned before, one needs to:
1) make sure the core never gets a thread related event
that corresponds to a thread the core doesn't know
about yet.
2) #1 implies that every target should register the main thread, even when
debugging a single-threaded app.
rs6000-nat.c, being a ptrace based target, already has that covered by
these:
http://sourceware.org/ml/gdb-patches/2008-08/msg00505.html
http://sourceware.org/ml/gdb-patches/2008-08/msg00171.html
3) #2 implies that a thread_stratum layer should decorate the main thread's
ptid with thread id info, instead of adding it again. That's
thread_change_ptid which is already in the tree.
The attached patch is a first try at it. Hopefully the changes are
self-explanatory and the comments point at what to do if things crash badly.
In case I've missed something big, it is my undertanding that the target stack
on AIX is:
threaded:
aix-thread.c (thread_stratum)
rs6000-nat.c extends inf-ptrace.c (process_stratum)
non-threaded:
rs6000-nat.c extends inf-ptrace.c (process_stratum)
This patch depends on these other patches:
This one for the fork-child.c change:
http://sourceware.org/ml/gdb-patches/2008-08/msg00505.html
This one for the inf-ptrace.c change:
http://sourceware.org/ml/gdb-patches/2008-08/msg00171.html
The thread_change_ptid function is already checked in.
I hope this helps.
--
Pedro Alves
[-- Attachment #2: aix_thread_always_a_thread.diff --]
[-- Type: text/x-diff, Size: 3533 bytes --]
2008-08-19 Pedro Alves <pedro@codesourcery.com>
* aix-thread.c (sync_threadlists): Claim the main thread. If no
thread is found, and we never had thread info bail out early.
(pd_update): Don't update inferior_ptid here.
---
gdb/aix-thread.c | 50 +++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 49 insertions(+), 1 deletion(-)
Index: src/gdb/aix-thread.c
===================================================================
--- src.orig/gdb/aix-thread.c 2008-08-19 16:37:56.000000000 +0100
+++ src/gdb/aix-thread.c 2008-08-19 18:06:04.000000000 +0100
@@ -679,6 +679,7 @@ sync_threadlists (void)
pthdb_pthread_t pdtid;
pthread_t pthid;
pthdb_tid_t tid;
+ infpid = PIDGET (inferior_ptid);
/* Accumulate an array of libpthdebug threads sorted by pthread id. */
@@ -717,6 +718,44 @@ sync_threadlists (void)
qsort (pbuf, pcount, sizeof *pbuf, pcmp);
+ /* If the main thread is still listed without extra lwp/tid info,
+ update its ptid and set its private field before synching the
+ lists. */
+
+ main_thread = find_thread_pid (infpid);
+ if (main_thread)
+ {
+ struct pd_thread *first;
+
+ /* We should have found at least one thread. */
+ /* Could it be we can get here with no threads while starting up
+ the inferior, and the thread library is still not
+ initialized? In that case, we'd just better skip over the
+ thread synching? */
+#if 0
+ gdb_assert (pcount > 0);
+#else
+ if (pcount == 0)
+ {
+ xfree (pbuf);
+ return;
+ }
+#endif
+
+ /* Assume the first listed is the main thread. */
+ first = &pbuf[0];
+
+ main_thread->private = xmalloc (sizeof (struct private_thread_info));
+ main_thread->private->pdtid = first->pdtid;
+ main_thread->private->tid = first->tid;
+
+ /* This also updates inferior_ptid if it is pointing at the main
+ thread (currently, it always is, but even if is wasn't
+ because we supported multi-process on AIX, it would be
+ ok). */
+ thread_change_ptid (main_thread->ptid, BUILD_THREAD (first->pthid, infpid));
+ }
+
/* Accumulate an array of GDB threads sorted by pid. */
gcount = 0;
@@ -727,7 +766,6 @@ sync_threadlists (void)
/* Apply differences between the two arrays to GDB's thread list. */
- infpid = PIDGET (inferior_ptid);
for (pi = gi = 0; pi < pcount || gi < gcount;)
{
if (pi == pcount)
@@ -816,6 +854,10 @@ pd_update (int set_infpid)
/* Define "current thread" as one that just received a trap signal. */
+ /* Can the bit below now ever return without a valid thread?
+ get_signaled_thread will return 0 if it doesn't find any
+ signalled thread. If sync_thread_lists didn't find any thread
+ yet, will iter_tid crash on the reference to thread->private? */
tid = get_signaled_thread ();
if (tid != 0)
thread = iterate_over_threads (iter_tid, &tid);
@@ -824,8 +866,12 @@ pd_update (int set_infpid)
else
{
ptid = thread->ptid;
+#if 0
+ /* sync_threadlists should be already taking care of updating
+ inferior_ptid, with the thread_change_ptid call. */
if (set_infpid)
inferior_ptid = ptid;
+#endif
}
return ptid;
}
@@ -940,6 +986,8 @@ new_objfile (struct objfile *objfile)
static void
aix_thread_attach (char *args, int from_tty)
{
+ /* inf-ptrace already adds the thread we attach to, and pd_activate
+ should end up claiming it. */
base_target.to_attach (args, from_tty);
pd_activate (1);
}
next reply other threads:[~2008-08-19 17:08 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-19 17:08 Pedro Alves [this message]
2008-08-20 13:14 ` Ulrich Weigand
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=200808191808.43011.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=uweigand@de.ibm.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