From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11205 invoked by alias); 8 Aug 2006 18:22:27 -0000 Received: (qmail 11188 invoked by uid 22791); 8 Aug 2006 18:22:27 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 08 Aug 2006 18:22:22 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1GAWDP-0006md-Vu; Tue, 08 Aug 2006 14:22:08 -0400 Date: Tue, 08 Aug 2006 18:22:00 -0000 From: Daniel Jacobowitz To: =?iso-8859-1?Q?Fr=E9d=E9ric?= Riss Cc: Frederic RISS , Andreas Schwab , gdb-patches@sources.redhat.com Subject: Re: [RFC] New threadnum command for breakpoints Message-ID: <20060808182207.GE24779@nevyn.them.org> Mail-Followup-To: =?iso-8859-1?Q?Fr=E9d=E9ric?= Riss , Frederic RISS , Andreas Schwab , gdb-patches@sources.redhat.com References: <1154093921.28300.236.camel@crx549.cro.st.com> <1154093921.28300.236.camel@crx549.cro.st.com> <20060728141339.GA15103@nevyn.them.org> <1154098563.28300.282.camel@crx549.cro.st.com> <20060728151434.GA17238@nevyn.them.org> <1154334744.28300.302.camel@crx549.cro.st.com> <20060731125311.GA1272@nevyn.them.org> <1154354425.28300.335.camel@crx549.cro.st.com> <1154376407.5120.27.camel@funkylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1154376407.5120.27.camel@funkylaptop> User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-08/txt/msg00050.txt.bz2 On Mon, Jul 31, 2006 at 10:06:47PM +0200, Frédéric Riss wrote: > Here's a code patch for discussion and a tentative doco patch. I've > chosen to initialize the variable early in handle_inferior_event, so > that it's set whatever happens. I thought that if we document it, it'd > rather be always set and not only for breakpoint condition evaluation. Good choice. My rule of thumb is that if I'd have to apologize for something in the manual, then I implemented it wrong - this is a perfect example of that :-) > 1. Should it change on a user requested thread switch? That would be a > simple patch to thread.c:switch_to_thread. But maybe documenting it as > 'the id of the last stopped thread' wouldn't be a bad idea. I don't > think GDB provides a way for the user to get this information (I mean > once he has selected another thread). This way 'thread $_gdb_thread' > would always bring you back to the stopped thread. What worries me here is that it locks us into a one-thread-at-a-time model. One of the unpleasant realities of thread debugging is that two threads can hit breakpoints simultaneously. You can pretend to the user that first one happened, then the other; or you can try to expose both. We haven't really thought about these issues. But, hey, it's probably going to be a major version bump if we ever do; so let's worry about it later :-) If you want it to be the last stopped thread, which seems reasonable, is there a better name we could give it? Or is $_gdb_thread sufficiently clear? > 2. Should we add support for read-only convenience variables? Writing in > $_gdb_thread makes no sense... but it causes no harm either. We already > have $bpnum in the same situation. I see some ways to support this: I don't think we need to worry about this. -- Daniel Jacobowitz CodeSourcery