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

[Kevin Buettner <kevinb at redhat dot com>]

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.

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).

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?

Kevin