From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2296 invoked by alias); 15 Nov 2012 20:58:28 -0000 Received: (qmail 2288 invoked by uid 22791); 15 Nov 2012 20:58:27 -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 20:58:21 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MDJ00200REZ9Q00@a-mtaout22.012.net.il> for gdb@sourceware.org; Thu, 15 Nov 2012 22:58:19 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDJ002K7RL7CP00@a-mtaout22.012.net.il>; Thu, 15 Nov 2012 22:58:19 +0200 (IST) Date: Thu, 15 Nov 2012 20:58:00 -0000 From: Eli Zaretskii Subject: Re: Time to expand "Program received signal" ? In-reply-to: <50A55196.4090303@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: <83vcd6shw7.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> <83mwyiu7j6.fsf@gnu.org> <50A52493.70807@redhat.com> <83boeyu3xz.fsf@gnu.org> <50A5340B.1000800@redhat.com> <837gpmu1k5.fsf@gnu.org> <50A55196.4090303@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/msg00048.txt.bz2 > Date: Thu, 15 Nov 2012 20:33:26 +0000 > From: Pedro Alves > CC: gnu@toad.com, mark.kettenis@xs4all.nl, brobecker@adacore.com, > gdb@sourceware.org > > >>>> It makes no sense to me to have "thread apply all FOO" do nothing > >>>> for non-threaded inferiors. > >>> > >>> No one said it should do nothing. "Main thread" implies there _is_ a > >>> thread. > >> > >> Yes, and my point is, if people have no problem in calling these special > >> cases single-threaded (where single implies more than zero), and if > >> as you say, there _is_ a thread, then the discussion we're having > >> of whether to say "Thread 1 received ..." is a bit silly. > > > > It's not silly, because these are two different use cases. In one use > > case, the _user_ types a thread-related command. In the other, _GDB_ > > talks about threads in the context of a single-threaded program. The > > former case cannot possibly cause user confusion, because it was the > > user who mentioned threads in the first place. > > > >> Either we assume non-threaded == single-threaded, and admit that in > >> that case non-threaded inferiors always have at least one thread, or > >> we don't, and "thread apply all " should not apply to non-threaded > >> inferiors. As you called it, it's a matter of self-consistency. > > > > The OP's concern was about the UI, not about GDB's own internal > > consistency. > > But I'm talking about UI! "thread apply all" is a user command. > If you'd expect "thread apply all bt" to produce a backtrace on a > non-threaded inferior, wouldn't you say that's because there _is_ _a_ > thread in the inferior? And if so then that thread must have a number > the user can refer to? And if so, what is the issue with always > consistently telling the user the thread that got the signal? > I can't honestly believe any real user would be confused by this. We are talking about 2 different users here. One is who types "thread apply all SOMETHING" -- this one evidently expects a single-threaded program to behave as a threaded one with 1 thread. The other user is who didn't type any thread-related commands, just had GDB print Thread XYZ received signal SIGFOO This one _might_ be confused. > Oh well, I'm beginning to consider dropping the patch for now. That was not my intent. I don't object to the patch.