From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16599 invoked by alias); 15 Nov 2012 18:27:41 -0000 Received: (qmail 16562 invoked by uid 22791); 15 Nov 2012 18:27:40 -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 18:27:28 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qAFIRP08021255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Nov 2012 13:27:25 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qAFIRNLp008405; Thu, 15 Nov 2012 13:27:24 -0500 Message-ID: <50A5340B.1000800@redhat.com> Date: Thu, 15 Nov 2012 18:27: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> In-Reply-To: <83boeyu3xz.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/msg00042.txt.bz2 On 15-11-2012 18:16, Eli Zaretskii wrote: >>> To propose a compromise: can we call the only thread "main thread" >>> instead of "thread 1"? >> >> Not really. You can end up with one thread in the list, even after >> the "main thread" having exited. > > 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). >> 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. That, would be a separate discussion... > >> My previous paste hinted at it. > > I must be blind or stupid, I know you're neither. :-) > because I don't see any hints as to how would a signal be announced in your example. (gdb) info inferiors Num Description Executable * 2 process 9943 /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/break 1 process 9939 /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/break (gdb) info threads Id Target Id Frame * 2 process 9943 "break" main (argc=1, argv=0x7fffffffdc48, envp=0x7fffffffdc58) at ../../../src/gdb/testsuite/gdb.base/break.c:89 1 process 9939 "break" main (argc=1, argv=0x7fffffffdc48, envp=0x7fffffffdc58) at ../../../src/gdb/testsuite/gdb.base/break.c:89 (gdb) Thread 1 received signal SIGFOO Thread 2 received signal SIGFOO Those would be different inferiors. > >> 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. 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. > >> 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). -- Pedro Alves