From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5312 invoked by alias); 10 Mar 2008 08:11:38 -0000 Received: (qmail 5301 invoked by uid 22791); 10 Mar 2008 08:11:36 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 10 Mar 2008 08:11:18 +0000 Received: (qmail 13974 invoked from network); 10 Mar 2008 08:11:16 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Mar 2008 08:11:16 -0000 From: Vladimir Prus To: Aleksandar Ristovski Subject: Re: [patch] fix for PR2424 Date: Mon, 10 Mar 2008 08:11:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <47CED9FB.7090904@qnx.com> <47D32B57.5020203@qnx.com> In-Reply-To: <47D32B57.5020203@qnx.com> Cc: gdb-patches@sources.redhat.com, nickrob@snap.net.nz MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803101111.13222.vladimir@codesourcery.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-03/txt/msg00086.txt.bz2 On Sunday 09 March 2008 03:12:07 you wrote: > Vladimir Prus wrote: > > FWIW, you don't say what function in mi-support.exp is changed, > > and it would be better if your patch was generated with -u (unified diff, > > 3 lines of context) -- the current one has no context at all, so I > > can only guess which function that is. > > Please find attached new diffs. > > > > > > Speaking of the problem itself -- in PR2424 you say: > > > > When inferior stops at temporary breakpoint, message is: > > *stopped,thread-id="0",....... > > without mentioning "reason=breakpoint-hit" > > This causes issues for multithreaded programs. > > > > What issues does it cause for MT programs? > > When inferior hits a temporary breakpoint, due to breakpoint removal the reason > for stop is "lost in translation". This leaves user guessing what the reason for > stop was. This is applicable to both single and multi threaded inferiors, but > gets more annoying when multiple threads exist since then client program (in my > case IDE - CDT) can not figure out which thread caused the stop The GDB output you have provided above actually includes thread id, so what problem does CDT have with figuring thread? In fact, CDT4's RxThread.java has the following: // We were stopped for some unknown reason, for example // GDB for temporary breakpoints will not send the // "reason" ??? still fire a stopped event. if (list.isEmpty()) { if (session.getMIInferior().isRunning()) { session.getMIInferior().setSuspended(); MIEvent event = new MIStoppedEvent(session, rr); session.fireEvent(event); } } > in addition to > not knowing the reason (I am not working on CDT but I was explained that missing > "reason" is to blame, and after the patch I proposed I was told things now work > as expected). So, could it be a CDT issue, after all? > @Nick: I think the breakpoint should be reported. The fact that it is temporary > doesn't make it much different than a regular breakpoint... but maybe I'm > missing something. Independent of actually CDT issue, I still think accurately reporting stop reason would be good. Can we probably look at breakpoints 'disp' field and either print "Breakpoint" or "Temporary breakpoint", and likewise either "breakpoint-hit" or "temporary-breakpoint-hit", in breakpoint.c:print_it_typical? - Volodya