This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Inadvertently run inferior threads
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb at sourceware dot org
- Date: Sat, 14 Mar 2015 18:17:04 +0200
- Subject: Re: Inadvertently run inferior threads
- Authentication-results: sourceware.org; auth=none
- References: <83h9tq3zu3 dot fsf at gnu dot org> <55043A63 dot 6020103 at redhat dot com> <8361a339xd dot fsf at gnu dot org> <5504555C dot 804 at redhat dot com> <83385736qt dot fsf at gnu dot org> <55045E87 dot 4040100 at redhat dot com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Sat, 14 Mar 2015 16:15:03 +0000
> From: Pedro Alves <palves@redhat.com>
> CC: gdb@sourceware.org
>
> > Yes, but in my case the called function didn't really start any
> > threads...
>
> If emacs doesn't start a new thread directly, it just looks to
> me that some Windows API function internally spawns them
> sometimes, then?
Yes, I think so.
> From gdb's perspective, it's exactly the same thing, it's all code
> in the inferior.
Certainly.
> >> (gdb) info threads
> >> Id Target Id Frame
> >> 2 Thread 0x7ffff7fc1700 (LWP 9903) "start-thread-in" (running)
> >> * 1 Thread 0x7ffff7fc2740 (LWP 9899) "start-thread-in" main () at start-thread-infcall.c:35
> >
> > What does "start-thread-in" signify in this display?
>
> It's the thread name, which defaults to the binary's file name name,
> which was "start-thread-infcall", but Linux trims it to 15 or so
> characters, IIRC. For this to work, you need to implement the
> target_thread_name hook. AFAICS, only linux-nat.c implements this.
Well, Windows threads don't really have names, AFAIK.
Thanks.