From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11434 invoked by alias); 17 May 2003 20:59:58 -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 11403 invoked from network); 17 May 2003 20:59:58 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 17 May 2003 20:59:58 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19H8n1-0006Rp-00; Sat, 17 May 2003 16:00:23 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19H8mV-0000P8-00; Sat, 17 May 2003 16:59:51 -0400 Date: Sat, 17 May 2003 20:59:00 -0000 From: Daniel Jacobowitz To: Kevin Buettner Cc: cgd@broadcom.com, ac131313@redhat.com, gdb-patches@sources.redhat.com Subject: Re: [WIP/RFC] MIPS registers overhaul Message-ID: <20030517205951.GA1507@nevyn.them.org> Mail-Followup-To: Kevin Buettner , cgd@broadcom.com, ac131313@redhat.com, gdb-patches@sources.redhat.com References: <1030514220025.ZM10373@localhost.localdomain> <3EC461C1.1080104@redhat.com> <1030516230550.ZM12582@localhost.localdomain> <1030517004052.ZM13153@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1030517004052.ZM13153@localhost.localdomain> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-05/txt/msg00314.txt.bz2 On Fri, May 16, 2003 at 05:40:52PM -0700, Kevin Buettner wrote: > On May 16, 4:24pm, cgd@broadcom.com wrote: > > > At Fri, 16 May 2003 23:06:50 +0000 (UTC), "Kevin Buettner" wrote: > > > On May 16, 3:50pm, cgd@broadcom.com wrote: > > > > > > > another reasonable way (but less efficient on a 64-bit part with a > > > > 64-bit FPU) would be: > > > > > > > > 0: > > > > 1: > > > > > > This is how the mips64 o32 rda transfers the FP registers. > > > > Hmm. > > > > OK, then, well, how do we ("gdb") tell the difference, since for o32 > > binaries it's reasonable to use either o32 RDA or (one might think) > > n32 RDA? > > Unfortunately, it isn't reasonable to use an ABI-specific RDA to debug > an application which uses a different ABI. It might kind of, sort of > work some of the time, but there are various things that won't work. > You've just identified one of the problems. > > Another one (and it's a doozie) is that thread debugging won't work > due to the ABI specific libthread_db.so library that's dlopen'd by > RDA. A native GDB (assuming that we did the necessary work to port it > to mips64-linux) would have the same problem. We've kicked around > some ideas for fixing this problem in the past. The only idea that > I've found compelling is from Alex Oliva (and perhaps others) who > suggested that it may be best for a "native" gdb to spawn an > ABI-specific rda or gdbserver and connect to it automatically. TBH, I'd rather like to see us develop an extended and more extensible remote protocol (on any number of people's TODO lists already!) and do _all_ native debugging this way. I don't think it's a pipe dream but it's definitely a future dream. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer