This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 4/5] Linux: Skip thread_db thread event reporting if PTRACE_EVENT_CLONE is supported
- From: Pedro Alves <palves at redhat dot com>
- To: Simon Marchi <simon dot marchi at ericsson dot com>, gdb-patches at sourceware dot org
- Date: Wed, 17 Dec 2014 13:04:31 +0000
- Subject: Re: [PATCH 4/5] Linux: Skip thread_db thread event reporting if PTRACE_EVENT_CLONE is supported
- Authentication-results: sourceware.org; auth=none
- References: <1418748834-27545-1-git-send-email-palves at redhat dot com> <1418748834-27545-5-git-send-email-palves at redhat dot com> <5490A306 dot 3060002 at ericsson dot com>
On 12/16/2014 09:24 PM, Simon Marchi wrote:
>> Before PTRACE_EVENT_CLONE (Linux 2.6), the only way to learn about new
>> threads in the inferior (to attach to them) or to learn about thread
>> exit was to coordinate with the inferior's glibc/runtime, using
>> libthread_db. That works by putting a breakpoint at a magic address
>> which is called when a new thread is spawned, or when a thread is
>> about to exit. When that breakpoint is hit, all threads are stopped,
>> and then GDB coordinates with libthread_db to read data structures out
>> of the inferior to learn about what happened.
>
> That is libthread_db's TD_CREATE event? Could you point out where that is
> done (stopping all the threads)?
When we're using libthread_db, the linux-thread-db.c target is pushed on
top of the target stack. So a target_wait call ends up in
linux-thread-db.c:thread_db_wait:
static ptid_t
thread_db_wait (struct target_ops *ops,
ptid_t ptid, struct target_waitstatus *ourstatus,
int options)
{
...
ptid = beneath->to_wait (beneath, ptid, ourstatus, options);
...
if (ourstatus->kind == TARGET_WAITKIND_STOPPED
&& ourstatus->value.sig == GDB_SIGNAL_TRAP)
/* Check for a thread event. */
check_event (ptid);
...
return ptid;
}
and the beneath->to_wait call ends up in linux_nat_wait -- _that_ is
what stops all threads just before returning to thread_db_wait.
> From the previous discussion with you, I
> was thinking that those breakpoints did not affect execution. I don't find
> any code in linux-thread-db.c that would do such a thing.
I think you're thinking of https://sourceware.org/ml/gdb-patches/2014-12/msg00210.html
What I was saying is that although the TD_DEATH event results in all
threads stopping and then gdb core resuming the target, it's not when the
TD_DEATH event breakpoint is hit that we call delete_thread, so that's
not when mi_thread_exit ends up called. Instead, after TD_DEATH, the
thread that is exiting actually still exists and is resumed (it still has
a few instructions to run inside glibc/pthread before actually calling
the exit syscall), and then later when the thread actually does the exit
syscall, waitpid returns an WIFEXITED status for it, and gdb _then_ calls
delete_thread, all within linux-nat.c, without stopping all threads.
>> This is exactly the same behavior as when debugging against remote
>> targets / gdbserver. I actually think that's a good thing (and as
>> such have listed this in the local/remote parity wiki page a while
>> ago), as the printing slows down the inferior. It's also a
>> distraction to keep bothering the user about short-lived threads that
>> she won't be able to interact with anyway. Instead, the user (and
>> frontend) will be informed about new threads that currently exist in
>> the program when the program next stops:
>
> Is this a consequence of the change of algorithm, or did you actively changed
> the behavior?
Both. :-) I made GDB do an implicit "info threads" just before
presenting a user-visible stop to the user a while ago. See the
update_thread_list call in normal_stop, added in git b57bacecd5 -- see
also references to local/remote parity in that commit's log.
And it's a consequence in that stopping linux-thread-db.c from calling
add_thread results in that update_thread_list call finding new and dead
threads then.
> From what I understand, gdb still attaches to the new thread as soon as it spawns
> (when it receives the PTRACE_EVENT_CLONE event),
Close, with PTRACE_EVENT_CLONE, gdb is automatically attached to the
new clone; the kernel does that for us.
> so it could print the notice when the event happens.
Right, see the code in linux_handle_extended_wait that does that,
in non-stop mode, only. I'd like to remove that bit soon enough
though. I've mentioned before that I regret having added it.
> Not that I mind, but I just want to understand.
Hope I made things a little clearer.
Thanks,
Pedro Alves