From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19145 invoked by alias); 1 Sep 2011 21:35:19 -0000 Received: (qmail 18898 invoked by uid 22791); 1 Sep 2011 21:35:18 -0000 X-SWARE-Spam-Status: No, hits=-2.3 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 21:34:53 +0000 Received: by fxg9 with SMTP id 9so1262286fxg.0 for ; Thu, 01 Sep 2011 14:34:52 -0700 (PDT) Received: by 10.223.24.208 with SMTP id w16mr460543fab.68.1314912892103; Thu, 01 Sep 2011 14:34:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.119.17 with HTTP; Thu, 1 Sep 2011 14:34:32 -0700 (PDT) In-Reply-To: <4E5F8753.8070003@indel.ch> References: <201108311909.22045.pedro@codesourcery.com> <4E5F8753.8070003@indel.ch> From: =?UTF-8?B?UGV0ciBIbHV6w61u?= Date: Thu, 01 Sep 2011 21:35:00 -0000 Message-ID: Subject: Re: Thread Specific Breakpoints in Remote Targets To: Raphael Zulliger Cc: gdb@sourceware.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: 2011-09/txt/msg00005.txt.bz2 On 1 September 2011 15:23, Raphael Zulliger wrote: > On 31.08.2011 20:09, Pedro Alves wrote: >> >> On Wednesday 31 August 2011 15:47:32, Tom Tromey wrote: >>> It sounds like you are making breakpoints on the target thread-specific >>> based on the current thread. =C2=A0But I thought we didn't (yet) have a= way >>> to inform the target that a given breakpoint was thread-specific (but I >>> don't know this area extremely well -- if I'm wrong I'd like to know >>> about it). >> >> You're right, we don't. > > Just to mention that: My company would be very interested in (optional) > 'thread specific breakpoints' support for remote targets. gdb could ask a > gdbstub whether it supports this feature (by the qSupported packet). > > In our case, our proprietary real-time OS already offers support for 'thr= ead > specific breakpoints' and it is definitely not an option for our system to > use the 'thread specific breakpoint emulation' performed by the gdb front= end > today as it would disrupt real-time behavior. The lack of this feature > causes major troubles for us during single-stepping, ... I think GDB's thread-specific breakpoints do something different than you expect: if user sets breakpoint specific to thread 5 then the other threads do not trigger the breakpoint (so far so good). However when the thread 5 arrives at the breakpoint then GDB stops _all_ threads even if the breakpoint was thread-specific. If you want to break only the thread which arrived at the breakpoint location and have the other threads continue running, then implement GDB's Non-Stop Mode [1], [2]. I think the thread-specific breakpoints will be almost unnecessary when you implement the non-stop mode. Users usually debug their own code which may live in multiple threads and specifying even one thread condition is slowdown. Of course if users place a breakpoint in a library used by multiple threads, then the thread-specific breakpoints will be useful. Still, the ability of thread-specific breakpoints would be useful to other remote stubs. By the way: when user does "next", "step", or "finish" GDB places a temporary internal breakpoint. Is the breakpoint thread-specific? I think it would be confusing to do "next" and wake up a different thread. Some IDE do not notify the user about the different thread. Furthermore the different thread may have identical stack (but processing unrelated data). Anyway it is difficult for the user to return to the correct thread since the frame of interest will be buried under sub-procedures the user was next-ing over and he may not even know the thread ID. Plus the next "next" may do the nastiness again. It would be useful if GDB placed thread-specific breakpoints for the commands. [1] http://sourceware.org/gdb/current/onlinedocs/gdb/Non_002dStop-Mode.html [2] http://sourceware.org/gdb/current/onlinedocs/gdb/Remote-Non_002dStop.ht= ml --=20 Petr Hluzin