From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12508 invoked by alias); 15 Nov 2012 19:07:54 -0000 Received: (qmail 12497 invoked by uid 22791); 15 Nov 2012 19:07:53 -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 mtaout23.012.net.il (HELO mtaout23.012.net.il) (80.179.55.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 15 Nov 2012 19:07:48 +0000 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MDJ00L00MFETM00@a-mtaout23.012.net.il> for gdb@sourceware.org; Thu, 15 Nov 2012 21:07:46 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDJ00LUEMGYNB80@a-mtaout23.012.net.il>; Thu, 15 Nov 2012 21:07:46 +0200 (IST) Date: Thu, 15 Nov 2012 19:07:00 -0000 From: Eli Zaretskii Subject: Re: Time to expand "Program received signal" ? In-reply-to: <50A5340B.1000800@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: <837gpmu1k5.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> 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/msg00043.txt.bz2 > Date: Thu, 15 Nov 2012 18:27:23 +0000 > From: Pedro Alves > CC: gnu@toad.com, mark.kettenis@xs4all.nl, brobecker@adacore.com, > gdb@sourceware.org > > > Doesn't GDB already know whether some threading library is linked into > > the program? If it does, then it knows whether another thread is > > possible or not. > > In some cases yes. But in general, no. Most importantly, it doesn't > in the case people could care the most, which is remote debugging (of > random bare metal targets and RTOSs). That's just too bad. > >> Then, if you have two inferiors, each of them is non-threaded, saying > >> "main thread" still doesn't tell you which of the inferiors got the > >> signal. > > > > Neither does "thread 1", AFAIU. > > It does. The number space of threads is the same for all inferiors. > There's only one thread 1. Which is even worse: now I still cannot know which inferior got the signal, and in addition I cannot even know which thread belongs to what inferior. > Thread 1 received signal SIGFOO > Thread 2 received signal SIGFOO > > Those would be different inferiors. Or 2 threads from the same inferior getting thread-specific signals. > >> 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. > >> E.g., this allows things like "b foo thread 1" to refer to the > >> main "thread" of a non-threaded program, even if it becomes > >> threaded by a later dlopen. > > > > Who said that the main thread is necessarily thread 1? You cannot > > count on that. > > I can, for non-threaded inferiors, which was my example. In that > case, you either count 0 threads, or 1 thread, depending on calling > it non-threaded, or single-threaded. But you can't ever have thread > N>1 before the inferior becomes multi-threaded (say, loads a threading > library). You are missing the point, I think. Again, the issue is not how GDB does its internal bookkeeping of threads. The issue is how to present that to the user of a single-threaded program who might be confused to hear anything about threads, because she didn't start any.