Re: Inadvertently run inferior threads

[Pedro Alves <palves at redhat dot com>]

On 03/14/2015 04:04 PM, Eli Zaretskii wrote:
>> Date: Sat, 14 Mar 2015 15:35:56 +0000
>> From: Pedro Alves <palves@redhat.com>
>> CC: gdb@sourceware.org
>>
>>> In that case, the cause of it getting out of sync is the new thread
>>> that was started (probably by Windows)?
>>
>> Calling a function that ends up starting new threads should
>> work OK, but indeed that seems to be broken...
> 
> 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?  From gdb's perspective, it's exactly the same
thing, it's all code in the inferior.

> 
> That said, thanks for the info, it could very well be relevant.
> 
>> (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.

Thanks,
Pedro Alves