Inadvertently run inferior threads

[Pedro Alves]

On 03/14/2015 04:17 PM, Eli Zaretskii wrote:
>> 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.

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