From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1765 invoked by alias); 31 Jan 2012 17:15:46 -0000 Received: (qmail 1654 invoked by uid 22791); 31 Jan 2012 17:15:43 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 31 Jan 2012 17:15:32 +0000 From: "palves at redhat dot com" To: gdb-prs@sourceware.org Subject: [Bug python/12967] event.inferior_thread does not exist in all-stop/sync mode Date: Tue, 31 Jan 2012 17:15:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: python X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: palves at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org X-SW-Source: 2012-q1/txt/msg00139.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=12967 --- Comment #5 from Pedro Alves 2012-01-31 17:14:41 UTC --- > right now I assume that the event handler is supposed to know that the current thread is the stopping thread (if that is even true). If that's true, it doesn't seem to be documented. The handler could also know that is true for non-stop. This makes it unnecessary and redundant to have event.inferior_thread in the first place. If we fixed event.inferior_thread, scripts that are working around this by looking at the current thread will still work. > /* thread events can either be thread specific or process wide. If gdb is > running in non-stop mode then the event is thread specific, otherwise > it is process wide. This is really bogus. A process wide event is something like a process exit, and is really orthogonal to all-stop/non-stop/itsets. :-( -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.