From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20570 invoked by alias); 3 Sep 2002 02:12:30 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20563 invoked from network); 3 Sep 2002 02:12:29 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 3 Sep 2002 02:12:29 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17m47C-0007pG-00; Mon, 02 Sep 2002 22:12:30 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17m3Aw-0002CE-00; Mon, 02 Sep 2002 22:12:18 -0400 Date: Mon, 02 Sep 2002 19:12:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Michael Snyder , gdb-patches@sources.redhat.com, "Van Assche, Bart" Subject: Re: gdbserver Message-ID: <20020903021218.GA8277@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Michael Snyder , gdb-patches@sources.redhat.com, "Van Assche, Bart" References: <6703765BD7FDD411AB0900508BFCACD3017D106E@bnbeluimex01.barconet.com> <20020830222342.GA32278@nevyn.them.org> <3D70010F.EAE68958@redhat.com> <20020831022307.GA9974@nevyn.them.org> <3D7414AC.5020100@ges.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D7414AC.5020100@ges.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-09/txt/msg00031.txt.bz2 On Mon, Sep 02, 2002 at 09:47:24PM -0400, Andrew Cagney wrote: > >On Fri, Aug 30, 2002 at 04:34:39PM -0700, Michael Snyder wrote: > > > >>Daniel Jacobowitz wrote: > > > >>> > >>> [Bart, please try this patch.] > >>> > >>> List folks, > >>> > >>> I think the time has come for generic_prepare_to_proceed to actually be > >>> used. The problem addressed by this patch is that PREPARE_TO_PROCEED > >>> is not a native-only macro (and not part of the target stack). So > >>> lin_lwp_prepare_to_proceed would be called when using gdbserver, and of > >>> course trap_ptid would be null_ptid or stale. > >>> generic_prepare_to_proceed works correctly for lin-lwp native > >>> debugging, and for remote debugging. This patch fixes an incorrect > >>> breakpoint hit after manually switching threads; i.e. the same > >>> breakpoint would be hit a second time. I'll try to write an > >>> independent test case. > >>> > >>> Patch look OK? > > > >> > >>Of course, a simpler and less intrusive fix would be to simply > >>define PREPARE_TO_PROCEED as generic_prepare_to_proceed, and > >>remove lin_lwp_prepare_to_proceed. > > Yes (well using set_gdbarch_prepare_to_proceed() :-). Hmm, things to do > for someone --- add a linux-tdep.c file? I've got a linux-nat already in my local tree, might as well do a linux-tdep... but then I'd need to hook this in to all the osabi stuff, and I'd rather not add it as GNU/Linux-specific only to make it global after we branch. Are you saying we should do the less invasive fix as above? It won't work unless I move the definition to the tm headers, since this affects cross targets too. I'd rather see the default changed as I proposed, if you're comfortable with it. Then after the branch we can look at the other platforms which have their own custom version. [I'm never quite clear what you mean when you answer a thread with "yes" :)] > >>I'm not necessarily objecting to this patch -- just pointing > >>out an alternative. If people think we're ready for this step, > >>it's fine with me. > > > > > >I think we're ready, but let's wait and see. For any non-threaded > >target generic_prepare_to_proceed won't do any harm, since it checks > >inferior_ptid != resume_ptid; for threaded targets, some version of > >this function must be better than none. > > Post branch, the whole lot can probably be ripped out. Probably. I don't know if the generic code will work right in HP/UX but I can't really see why it wouldn't.... I don't suppose you're interested in ripping out HP/UX period after the branch? :) We may have a PA-RISC maintainer now but he didn't sound enthusiastic about getting HP/UX dumped on him too. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer