From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15962 invoked by alias); 15 Mar 2003 20:51:43 -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 15912 invoked from network); 15 Mar 2003 20:51:42 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 15 Mar 2003 20:51:42 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18uKWS-00045s-00; Sat, 15 Mar 2003 16:53:00 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18uId1-0004EP-00; Sat, 15 Mar 2003 15:51:39 -0500 Date: Sat, 15 Mar 2003 20:51:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: RFC: threads PREPARE_TO_PROCEED patch Message-ID: <20030315205139.GA16167@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> <20030314183529.GA18511@nevyn.them.org> <200303152039.h2FKdEnO000331@elgar.kettenis.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303152039.h2FKdEnO000331@elgar.kettenis.dyndns.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-03/txt/msg00343.txt.bz2 On Sat, Mar 15, 2003 at 09:39:14PM +0100, Mark Kettenis wrote: > Date: Fri, 14 Mar 2003 13:35:29 -0500 > From: Daniel Jacobowitz > > > 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. > > OK, but generic_prepare_to_proceed() is perfectly usable on a native > GNU/Linux GDB too, isn't it? Yes, exactly. > 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. > > It seems to be a property of the OS to me. In its current > incarnation, gdbarch does includes details of both the architecture > (ISA) and the OS (OS/ABI). So gdbarch seems to be the correct place > for PREPARE_TO_PROCEED to me. So yes, I think you should add it to > all relevant Linux gdbarch init functions. I can do that; I'll put a patch together. But I must admit that I don't really agree. It seems to be a property of the threads implementation for the target instead. Consider this case: if someone wanted to write a remote protocol stub for HP/UX. They wouldn't want the HP/UX version of PREPARE_TO_PROCEED naturally, since that's native-only. They'd want most likely generic_prepare_to_proceed. The default function isn't useful; it doesn't support switching threads correctly. (Incidentally, from reading the HP/UX implementation, I believe that using generic_prepare_to_proceed would work there too. It wouldn't work for the Mach 3.0 implementation as-is but I think it could be made to work. I'm not volunteering; are either hppa*-*-osf* or mips*-*-mach3* still living? Perhaps we should deprecate them next release.) -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer