From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12016 invoked by alias); 15 Nov 2012 16:58:58 -0000 Received: (qmail 11999 invoked by uid 22791); 15 Nov 2012 16:58:56 -0000 X-SWARE-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 15 Nov 2012 16:58:47 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MDJ00000GG64O00@a-mtaout22.012.net.il> for gdb@sourceware.org; Thu, 15 Nov 2012 18:58:46 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDJ00N8JGHX2O30@a-mtaout22.012.net.il>; Thu, 15 Nov 2012 18:58:46 +0200 (IST) Date: Thu, 15 Nov 2012 16:58:00 -0000 From: Eli Zaretskii Subject: Re: Time to expand "Program received signal" ? In-reply-to: <50A4C5AA.70304@redhat.com> To: Pedro Alves Cc: gnu@toad.com, mark.kettenis@xs4all.nl, brobecker@adacore.com, gdb@sourceware.org Reply-to: Eli Zaretskii Message-id: <83mwyiu7j6.fsf@gnu.org> References: <50A13A4E.3020000@redhat.com> <20121113162530.GX4847@adacore.com> <201211131640.qADGeKhs021376@glazunov.sibelius.xs4all.nl> <50A281BC.9030802@redhat.com> <201211132240.qADMeB2N032392@new.toad.com> <50A371C6.3080307@redhat.com> <201211141954.qAEJsQ2N026469@new.toad.com> <50A4C5AA.70304@redhat.com> X-IsSubscribed: yes 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 X-SW-Source: 2012-11/txt/msg00035.txt.bz2 > Date: Thu, 15 Nov 2012 10:36:26 +0000 > From: Pedro Alves > CC: Mark Kettenis , brobecker@adacore.com, gdb@sourceware.org > > > GDB shouldn't mention > > threads at all, unless the program being debugged has more than a > > single thread. > > See? If it has a single thread, GDB calls that thread "thread 1". To propose a compromise: can we call the only thread "main thread" instead of "thread 1"? > GDB's model calls the unit of scheduling in the inferior that got > the signal "Thread N". You can "thread N" to switch to it. > > (gdb) maint print target-stack > The current target stack is: > - child (Unix child process) > - exec (Local exec file) > - None (None) > (gdb) info threads > Id Target Id Frame > * 1 process 9939 "break" main (argc=1, argv=0x7fffffffdc48, envp=0x7fffffffdc58) at ../../../src/gdb/testsuite/gdb.base/break.c:89 This just says that GDB's model is self-consistent. Being consistent doesn't necessarily mean being correct ;-)