From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29418 invoked by alias); 14 Mar 2003 18:35:41 -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 29342 invoked from network); 14 Mar 2003 18:35:41 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 14 Mar 2003 18:35:41 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18tvvC-0001hA-00; Fri, 14 Mar 2003 14:36:54 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18tu1h-0004sV-00; Fri, 14 Mar 2003 13:35:29 -0500 Date: Fri, 14 Mar 2003 18:35:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: RFC: threads PREPARE_TO_PROCEED patch Message-ID: <20030314183529.GA18511@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sources.redhat.com References: <20030313233251.GA22466@nevyn.them.org> <86of4d7tle.fsf@elgar.kettenis.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86of4d7tle.fsf@elgar.kettenis.dyndns.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-03/txt/msg00330.txt.bz2 On Fri, Mar 14, 2003 at 06:20:45PM +0100, Mark Kettenis wrote: > Daniel Jacobowitz writes: > > > This patch aims to avoid problems when using a native GNU/Linux debugger > > (which supports threads) with a remote protocol stub that supports threads. > > lin_lwp_prepare_to_proceed gets called anyway, but it doesn't function, > > because the trap_ptid is (unsurprisingly) not set; since it's internal > > accounting for lin-lwp. This patch makes us use generic_prepare_to_proceed > > instead of the old default_prepare_to_proceed or lin_lwp_prepare_to_proceed; > > it can get everything it needs from infrun. If I recall correctly, it also, > > as per the FIXME, supports switching threads better than the lin_lwp version > > did. But I haven't tested that in a long time. > > > > This is a patch from last year, just before 5.3 was branched. At the time > > it was decided to be generally right, but too risky for 5.3. Well, now I've > > gone and sat on it for too long, and we're coming up on 5.4. But I've been > > using this patch since August without any problems. Depending on consensus > > I'd like to check it in either before or after we branch for release. > > > > Thoughts, thread maintainers? > > I'm not quite sure whether changing the gdbarch default is a good > idea, but replacing lin_lwp_prepare_to_proceed with > generic_prepare_to_proceed has been the intention all along. Well, let me describe the problem I'm trying to solve; I'd like your opinion on how to approach it. When using gdbserver, we need to have generic_prepare_to_proceed. Not the lin_lwp version, and not the "default" one from arch-utils. The former won't work and the latter doesn't do enough. So cross debuggers need to pick this up. Note that this is a property of the target. Not of the architecture. I'm not sure PREPARE_TO_PROCEED belongs in gdbarch at all. It's only defined by Mach3, HP/UX, and Linux; it's undefined for x86-64-linux (why???). I could set it in all the Linux gdbarch init functions that I care about, but that doesn't seem like much of a solution. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer