From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8221 invoked by alias); 23 May 2003 20:45:19 -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 8107 invoked from network); 23 May 2003 20:45:16 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 23 May 2003 20:45:16 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id F12222B2F; Fri, 23 May 2003 16:45:07 -0400 (EDT) Message-ID: <3ECE8853.3020906@redhat.com> Date: Fri, 23 May 2003 20:45: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 Cc: Kevin Buettner , cgd@broadcom.com, gdb-patches@sources.redhat.com Subject: Re: [WIP/RFC] MIPS registers overhaul References: <3ECA9587.4090407@redhat.com> <3ECB9C8F.1060706@redhat.com> <20030521154134.GA7667@nevyn.them.org> <3ECBA393.9020904@redhat.com> <20030521165816.GA8784@nevyn.them.org> <1030521183234.ZM31903@localhost.localdomain> <3ECBD034.3080504@redhat.com> <20030522003151.GA15642@nevyn.them.org> <3ECE66BD.7060700@redhat.com> <20030523184439.GA7928@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00468.txt.bz2 > On Fri, May 23, 2003 at 02:21:49PM -0400, Andrew Cagney wrote: > >> > >> >>Er, it's the same deal as for SPARC. If GDB is built against the 64 bit >> >>debug interface, it can debug both 32 and 64 bit applications. This is >> >>the debuggers view, not the program being run's view. > >> > >> > >> >But the point is that the debugger's view of a 32-bit application on >> >MIPS is of a 32-bit ISA. That's all that's available. You get 32-bit >> >registers from the kernel. > >> >> That isn't true. CF the embedded case. The ISA can be 64 bits, but the >> ABI 32 bits. This argument is becomming circular. > > > I'm not talking about the embedded case! I never said that we should > always use a 32-bit protocol when debugging a 32-bit ABI. I said that > in this case, using rda or gdbserver on a hosted system, it doesn't > make any sense to use the 64-bit protocol. GDB shouldn't be differentiating. It's a remote.c problem. >> GDB has to make a choice. Either hack the tdep code so that it tries to >> get the user, register, and target ABIs to all line up, or select an >> underlying canonical ISA and expect targets to map their register values >> onto that. Selecting a definitive 64 bit ISA means that the tdep code >> works in all cases - the target is made responsibile for resolving self >> inflicted esoteric edge cases. > > > Then why have the 32-bit protocol at all, besides compatibility with > existing stubs? Just waste the transfer time for the unused bits all > the time. If the self inflicting esoteric remote target and the regcache were no longer connected at the hip, more efficient register protocols could be used. Anyway some packing techniques: - T packets (available now) - proposed short T register values - proposed [pP] packet to request additional registers - proposed ``!'' [for network byte ordered] register values - use of run-length encoding (available now?) - use of -1 to encode 0xffffffffffffffff (available now?) >> Note here that the self inflicting esoteric target is remote.c, it is >> still tied to the register cache at the hip :-( Andrew