From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10936 invoked by alias); 15 Nov 2012 20:33:42 -0000 Received: (qmail 10928 invoked by uid 22791); 15 Nov 2012 20:33:41 -0000 X-SWARE-Spam-Status: No, hits=-7.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 15 Nov 2012 20:33:32 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qAFKXUiL026399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Nov 2012 15:33:30 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qAFKXRYg024030; Thu, 15 Nov 2012 15:33:27 -0500 Message-ID: <50A55196.4090303@redhat.com> Date: Thu, 15 Nov 2012 20:33:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Eli Zaretskii CC: gnu@toad.com, mark.kettenis@xs4all.nl, brobecker@adacore.com, gdb@sourceware.org Subject: Re: Time to expand "Program received signal" ? 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> In-Reply-To: <837gpmu1k5.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00046.txt.bz2 On 15-11-2012 19:08, Eli Zaretskii wrote: >> Date: Thu, 15 Nov 2012 18:27:23 +0000 >> From: Pedro Alves >>>> 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, (It's not worse than "Program received signal", which tells you nothing.) Ideally you should be able to. I tend to think of it as a separate problem. We could say something like "Inferior I, thread T received signal". "Thread I.T" is more compact, and more "standard", if it weren't for the current flat numbering scheme. If there's a good suggestion (that is implementable and correct; just suppressing the thread number when there's only a single thread in the inferior is not) to tweak to output, I'll implement it. > and in addition I cannot even know which thread belongs to > what inferior. Yes, that's a problem. But it's a larger problem than this specific "received signal" issue though. > >> 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. Sure, but the important point is that there's a unique identifier, better than "Program". And it seems to me that at least mentioning "Thread N" when there's only one thread would still be desirable. > >>>> 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. > >>>> 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. I'm explaining that we can refer to the main thread of non-threaded programs in the CLI, which is a UI. That the way to do that, is to refer to thread 1. IOW, in the UI, the main thread of non-threaded programs is thread 1. > 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. I don't believe any user would be confused. If there's any little confusion at all, it can't seriously go beyond: "What's this thread 1 GDB is talking about? I didn't start any! - It's the main thread. - Oh, makes sense." Oh well, I'm beginning to consider dropping the patch for now. -- Pedro Alves