From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22803 invoked by alias); 24 Dec 2002 14:51:57 -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 22796 invoked from network); 24 Dec 2002 14:51:56 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 24 Dec 2002 14:51:56 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18QsHt-0006QJ-00; Tue, 24 Dec 2002 10:52:13 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18QqQa-0007of-00; Tue, 24 Dec 2002 09:53:04 -0500 Date: Tue, 24 Dec 2002 09:25:00 -0000 From: Daniel Jacobowitz To: Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Add support for 64-bit MIPS GNU/Linux targets Message-ID: <20021224145304.GA29615@nevyn.them.org> Mail-Followup-To: Kevin Buettner , gdb-patches@sources.redhat.com References: <1021223225021.ZM25698@localhost.localdomain> <20021223235639.GA6927@nevyn.them.org> <1021224062810.ZM26995@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1021224062810.ZM26995@localhost.localdomain> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-12/txt/msg00664.txt.bz2 On Mon, Dec 23, 2002 at 11:28:11PM -0700, Kevin Buettner wrote: > On Dec 23, 6:56pm, Daniel Jacobowitz wrote: > > > > @@ -95,15 +109,15 @@ supply_gregset (elf_gregset_t *gregsetp) > > > memset (zerobuf, 0, MAX_REGISTER_RAW_SIZE); > > > > > > for (regi = EF_REG0; regi <= EF_REG31; regi++) > > > - supply_register ((regi - EF_REG0), (char *)(regp + regi)); > > > + supply_32bit_reg ((regi - EF_REG0), (char *)(regp + regi)); > > > > > > - supply_register (LO_REGNUM, (char *)(regp + EF_LO)); > > > - supply_register (HI_REGNUM, (char *)(regp + EF_HI)); > > > + supply_32bit_reg (LO_REGNUM, (char *)(regp + EF_LO)); > > > + supply_32bit_reg (HI_REGNUM, (char *)(regp + EF_HI)); > > > > > > - supply_register (PC_REGNUM, (char *)(regp + EF_CP0_EPC)); > > > - supply_register (BADVADDR_REGNUM, (char *)(regp + EF_CP0_BADVADDR)); > > > - supply_register (PS_REGNUM, (char *)(regp + EF_CP0_STATUS)); > > > - supply_register (CAUSE_REGNUM, (char *)(regp + EF_CP0_CAUSE)); > > > + supply_32bit_reg (PC_REGNUM, (char *)(regp + EF_CP0_EPC)); > > > + supply_32bit_reg (BADVADDR_REGNUM, (char *)(regp + EF_CP0_BADVADDR)); > > > + supply_32bit_reg (PS_REGNUM, (char *)(regp + EF_CP0_STATUS)); > > > + supply_32bit_reg (CAUSE_REGNUM, (char *)(regp + EF_CP0_CAUSE)); > > > > > > /* Fill inaccessible registers with zero. */ > > > supply_register (UNUSED_REGNUM, zerobuf); > > > > Correct me if I'm wrong, but native thread debugging isn't going to > > work if you do this. proc-service.c calls supply_gregset directly and > > everything blows up. > > True, but see below. > > > Is it time to multiarch supply_gregset? > > Maybe. > > I've given this some thought and it seems to me that if we're going to > multiarch supply_gregset, we'll have to change its prototype; basically, > we'll have to pass gregsetp around as a void *. I'm not against this, > but I think it needs to be discussed first. (Also, either the regset > size or perhaps an allocation function will need to be provided using > a multiarch method.) > > There are several other problems with native thread support on Linux/MIPS: > > 1) For o32, the core gregset layout is incompatible with that used for > threads. (The sizes of the arrays and the layouts are different.) > Hopefully this won't be a problem for n32 and n64. I don't believe that's currently true. Native thread support _works_ on O32; I spent a great deal of time nagging to get all the appropriate gregsets corrected. You should find that a prgregset_t is just a typedef to an elf_gregset_t in any recent (past six/eight months?) glibc. > 2) There are actually three libthread_db.so libraries, one each for > o32, n32, and n64. Yet the gdb binary will (obviously) use only > one of these ABIs. It's not possible to dlopen() a library of > a differing ABI, which (unfortunately) means that a given gdb > binary can only provide thread support for only one ABI. > > There are, of course, several technical options open to us to > work around this difficulty. One approach is to arrange for > each of these libraries to be built to use the ABI that gdb uses, > yet still know the details about the target ABI. Another is to > somehow combine the knowledge concerning the three ABIs into a > single libthread_db.so library. There may be other approaches > too, but at the moment, I don't think any of these solutions > will be trivial to implement (though some are clearly easier than > others). Welcome to all the problems with the libthread_db.so model. Bugger. Gdbserver will work, since it links to rather than dlopening libthread_db, so one can simply provide gdbserver, gdbserver-n32, etc. That's not ideal of course. I don't know what can be done about this. I doubt libthread_db can handle something for a different ABI and it'll be a royal pain to make it do so. > > Anyway, given all of the above it seems to me that native thread support > for Linux/MIPS which supports all three ABIs is quite a ways off. > > [...] > > So: > > supply_gregset? > > GDBSERVER_DEPFILES nit > > tm-linux64 nit > > > > Otherwise, this is OK. > > Thanks for the quick (but thorough) patch review! > > I'll fix the GDBSERVER_DEPFILES and tm-linux64 nits, but the > supply_gregset issue will require further discussion. In the interim, > how would you like to proceed? Since it won't affect thread support for 32-bit MIPS, I've no objection to committing it now. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer