Re: Inadvertently run inferior threads
Pedro Alves <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
On 03/14/2015 04:17 PM, Eli Zaretskii wrote: >> Date: Sat, 14 Mar 2015 16:15:03 +0000 >> From: Pedro Alves <[email protected]> >> CC: [email protected] >> >>> 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. Last I looked, Visual Studio does support that. It's based on a funny hack: https://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx I think the idea is that the debugger intercepts that MS_VC_EXCEPTION SEH exception and reads the thread name off of the inferior memory pointed at by the THREADNAME_INFO structure. Thanks, Pedro Alves