From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7250 invoked by alias); 16 Nov 2012 00:22:52 -0000 Received: (qmail 7242 invoked by uid 22791); 16 Nov 2012 00:22:51 -0000 X-SWARE-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_BRBL_LASTEXT,RCVD_IN_HOSTKARMA_YE,RCVD_IN_MSPIKE_BL,RCVD_IN_MSPIKE_L3,RCVD_IN_NJABL_RELAY,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from new.toad.com (HELO new.toad.com) (209.237.225.253) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 16 Nov 2012 00:22:44 +0000 Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id qAG0Mb2N030287; Thu, 15 Nov 2012 16:22:37 -0800 Message-Id: <201211160022.qAG0Mb2N030287@new.toad.com> To: Paul_Koning@Dell.com cc: gnu@toad.com, tromey@redhat.com, palves@redhat.com, mark.kettenis@xs4all.nl, brobecker@adacore.com, gdb@sourceware.org Subject: Re: Time to expand "Program received signal" ? In-reply-to: References: <50A13A4E.3020000@redhat.com> <20121113162530.GX4847@adacore.com> <201211131640.qADGeKhs021376@glazunov.sibelius.xs4all.nl> <50A281BC.9030802@redhat.com> <201211132240.qADMeB2N032392@new.toad.com> <871ufu1zyx.fsf@fleche.redhat.com> <201211152221.qAFML62N024464@new.toad.com> Comments: In-reply-to message dated "Thu, 15 Nov 2012 22:26:27 +0000." Date: Fri, 16 Nov 2012 00:22:00 -0000 From: John Gilmore 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/msg00051.txt.bz2 > >> John> GDB shouldn't mention threads at all, unless the program being debugged > >> John> is multi-threaded. > > But you didn't address the issue that you can't readily tell whether a program is multi-threaded. It may have had multiple threads but it doesn't now, or it may have more later. This may be true even though it's not linked to libpthread -- that library might not even exist on the OS in question, or it may be linked in static, or the program may simply call the kernel's "create me a thread" syscall. This isn't rocket science. If the program "used to" have multiple threads, and only has one now, it should be treated as single-threaded -- until it creates another thread. If GDB can't tell whether there's more than one thread, it has to treat the program as single-threaded. What does GDB do if the user sets "scheduler-locking on" and GDB isn't sure whether the target has multiple threads? In general, GDB should not let itself get into a situation where it doesn't know whether there are other threads, since in that state it will violate its own specifications. Just as GDB shouldn't ever print a bogus value for a variable. The user should be able to depend on anything GDB tells them about the program. If they have to debug GDB, or work around well-known bugs in it that make it lie about the state of the program, they can't trust what it tells them about their own program. John