From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22882 invoked by alias); 8 Aug 2006 19:43:12 -0000 Received: (qmail 22873 invoked by uid 22791); 8 Aug 2006 19:43:11 -0000 X-Spam-Check-By: sourceware.org Received: from smtp3-g19.free.fr (HELO smtp3-g19.free.fr) (212.27.42.29) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 08 Aug 2006 19:43:09 +0000 Received: from [192.168.0.11] (pas38-3-82-229-199-15.fbx.proxad.net [82.229.199.15]) by smtp3-g19.free.fr (Postfix) with ESMTP id C66D649135; Tue, 8 Aug 2006 21:43:06 +0200 (CEST) Subject: Re: [RFC] New threadnum command for breakpoints From: =?ISO-8859-1?Q?Fr=E9d=E9ric?= Riss To: Daniel Jacobowitz Cc: Andreas Schwab , gdb-patches@sources.redhat.com In-Reply-To: <20060808182207.GE24779@nevyn.them.org> 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> <20060808182207.GE24779@nevyn.them.org> Content-Type: text/plain Date: Tue, 08 Aug 2006 19:43:00 -0000 Message-Id: <1155066173.5130.52.camel@funkylaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit 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/msg00055.txt.bz2 Hi ! > > 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 :-) Yes, agreed :-). But the issue is quite interesting... trying to come up with a model that would allow to test for multiple thread simultaneously is a nice exercise. Going slightly off-topic, do you really think that reporting simultaneous hits would be a real gain? I don't think it's so important as long as you don't miss any of the hits. Threading isn't totally deterministic, thus the fact that multiple threads have hit a breakpoint at the same time is just an 'accident' and doesn't bring any additional information to the user. Of course this reasoning requires that targets can guarantee that you won't miss any of the hits. Now back to real code... > 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? I'm not sure. The name itself looks fine to me but, speaking as a user, I find the leading '_' a bit strange. It seems to imply something about the variable, but it's not clear what. If it was a convention and all variables would share the same prefix, then it wouldn't feel so strange. On the other side if we want to use a common convention we've got to start somewhere. Anyway that's just a personal feeling, and really no big deal, maybe others could share their opinion? Fred.