Re: [RFA] Add support for 64-bit MIPS GNU/Linux targets

[Daniel Jacobowitz <drow at mvista dot com>]

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