From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2790 invoked by alias); 1 Sep 2011 15:34:06 -0000 Received: (qmail 2612 invoked by uid 22791); 1 Sep 2011 15:34:05 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-fx0-f41.google.com (HELO mail-fx0-f41.google.com) (209.85.161.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 01 Sep 2011 15:33:49 +0000 Received: by fxg9 with SMTP id 9so928197fxg.0 for ; Thu, 01 Sep 2011 08:33:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.39.193 with SMTP id h1mr468996fae.135.1314891228506; Thu, 01 Sep 2011 08:33:48 -0700 (PDT) Received: by 10.223.118.144 with HTTP; Thu, 1 Sep 2011 08:33:48 -0700 (PDT) In-Reply-To: <201108311942.00429.pedro@codesourcery.com> References: <201108311909.22045.pedro@codesourcery.com> <201108311942.00429.pedro@codesourcery.com> Date: Thu, 01 Sep 2011 15:34:00 -0000 Message-ID: Subject: Re: Thread Specific Breakpoints in Remote Targets From: Josh Watt To: Pedro Alves Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: 2011-09/txt/msg00004.txt.bz2 > There's that backwards compatibility thing. =A0You'd have to come up with > a way to get the current behavior of "breakpoint applies to all threads > of this process". =A0You'd need to add some new meaning to something > like Hg0/HgPID.0, which is close, but that's not what it means > today, so without other changes, you'd be left with the target not > knowing what this particular gdb is trying to say (because you don't > know whether the connecting gdb understands "thread specific" or not). Makes sense. Unless I'm missing something, I don't believe this would be too difficult to implement. Most of the code would live in remote.c and would require a new packet for handling thread breakpoints. Would something like this be OK, or did you have something else in mind? vThreadBreak;addr;kind;thread-id The only other question I currently have is how should the thread id be communicated to remote.c? Should the global inferior_ptid be used, or would we add another member to the struct bp_target_info that contains the thread ID? -- ~JPEW