From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114011 invoked by alias); 14 Mar 2015 16:17:18 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 113998 invoked by uid 89); 14 Mar 2015 16:17:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout26.012.net.il Received: from mtaout26.012.net.il (HELO mtaout26.012.net.il) (80.179.55.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 14 Mar 2015 16:17:16 +0000 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NL700K00MF62100@mtaout26.012.net.il> for gdb@sourceware.org; Sat, 14 Mar 2015 18:17:56 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NL700DPVMLVCQ60@mtaout26.012.net.il>; Sat, 14 Mar 2015 18:17:56 +0200 (IST) Date: Sat, 14 Mar 2015 16:17:00 -0000 From: Eli Zaretskii Subject: Re: Inadvertently run inferior threads In-reply-to: <55045E87.4040100@redhat.com> To: Pedro Alves Cc: gdb@sourceware.org Reply-to: Eli Zaretskii Message-id: <83y4mz1rlr.fsf@gnu.org> References: <83h9tq3zu3.fsf@gnu.org> <55043A63.6020103@redhat.com> <8361a339xd.fsf@gnu.org> <5504555C.804@redhat.com> <83385736qt.fsf@gnu.org> <55045E87.4040100@redhat.com> X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00039.txt.bz2 > Date: Sat, 14 Mar 2015 16:15:03 +0000 > From: Pedro Alves > 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.