Re: Inadvertently run inferior threads
Pedro Alves <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
On 03/14/2015 04:04 PM, Eli Zaretskii wrote: >> Date: Sat, 14 Mar 2015 15:35:56 +0000 >> From: Pedro Alves <[email protected]> >> CC: [email protected] >> >>> 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