From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6429 invoked by alias); 16 Mar 2003 21:24:16 -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 6358 invoked from network); 16 Mar 2003 21:24:15 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 16 Mar 2003 21:24:15 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 470832B11; Sun, 16 Mar 2003 16:24:14 -0500 (EST) Message-ID: <3E74EB7E.8070603@redhat.com> Date: Sun, 16 Mar 2003 21:24:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz , Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: RFC: threads PREPARE_TO_PROCEED patch References: <20030313233251.GA22466@nevyn.them.org> <86of4d7tle.fsf@elgar.kettenis.dyndns.org> <20030314183529.GA18511@nevyn.them.org> <200303152039.h2FKdEnO000331@elgar.kettenis.dyndns.org> <20030315205139.GA16167@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00353.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. Needing to change one of GDB's architecture methods dependant on a target attribute (local or remote) suggests that the method should be in the target vector. >> 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.) Obsoleting hppa*-*-osf* was sent to announce list (no objection so far). Can you formally propose removing mips*mach3 here (and create a bug report) that can quickly happen. If you both really think that PREPARE_TO_PROCEED is wrong, deprecate it (details left as an exercise for the reader). Andrew