aboutsummaryrefslogtreecommitdiff
path: root/gdb/configure.tgt
diff options
context:
space:
mode:
authorJoel Brobecker <brobecker@gnat.com>2011-01-13 16:23:33 +0000
committerJoel Brobecker <brobecker@gnat.com>2011-01-13 16:23:33 +0000
commitf688d93f0ba11335108bbb3979a2d3ea096f574f (patch)
treefa8a4bfb612c708e0cda2372c411e5029d7aecf5 /gdb/configure.tgt
parent1b89e62fe38f55605f23b7026b70a6d184c0fae5 (diff)
downloadgdb-f688d93f0ba11335108bbb3979a2d3ea096f574f.zip
gdb-f688d93f0ba11335108bbb3979a2d3ea096f574f.tar.gz
gdb-f688d93f0ba11335108bbb3979a2d3ea096f574f.tar.bz2
[hpux/ttrace] Determine attached process LWP immediately after attaching.
When attaching to a process, the ttrace interface was creating a ptid with a null LWP, because it did not have it yet. This LWP was then set as soon as we received our first event from our inferior, during our first wait. Similarly, the allocation of the thread private info was also defered. This works on PA/HP-UX, because we immediately perform a wait to pop the event triggered by the attach. We can use that event to extract the thread's LWP. But this does not work for IA64/HP-UX, because the attach no longer triggers an event, and thus a wait should NOT be performed (such a wait would simply block indefinitely). It is actually possible, however, to determine the thread's LWP. This change therefore adjusts the attach code to create a thread with the correct LWP set, as well as with its private info allocated. Same thing for all the other threads. gdb/ChangeLog: [ttrace] Compute thread list immediately after attach. * inf_ttrace_attach (inf_ttrace_create_threads_after_attach): New subprogram. (inf_ttrace_attach): Use it.
Diffstat (limited to 'gdb/configure.tgt')
0 files changed, 0 insertions, 0 deletions