Re: RFA: Support libthread_db xregs interface

[Andrew Cagney <cagney@gnu.org>]

>    Sender: jimb@zenia.home
>    Cc: gdb-patches@sources.redhat.com
>    From: Jim Blandy <jimb@redhat.com>
>    Date: 25 Aug 2004 00:07:07 -0500
> 
>    Andrew Cagney <cagney@gnu.org> writes:
>    > > + v:=:const struct regset *:xregs_regset:::0
>    > 
>    > Mark's regset change added both the "regset.h" object and the
>    > regset_from_core_section architecture method.  They, together, replace
>    > the old *-nat.c:fill_regset et.al. calls.
>    > 
>    > Can we implement the equivalent here for ptrace/thread-db?
> 
>    Not sure what you mean.  This change lets a gdbarch object specify a
>    regset which the libthread_db support code will then use to read and
>    write additional registers beyond those covered by gregset_t and
>    fpregset_t.  So this change does provide a regset.h-style regset for
>    libthread_db.  That's what you're looking for, right?
> 
> I'm not sure, but I presume Andrew is asking you to implement a
> regset_from_xxx function for use by ptrace/thread-db, instead of
> explicitly adding the xregset to the architecture vector.  Your
> current patch leaves the supply_gregset() and supply_fpregset() calls
> as they are.  That's fine for now, but in the long run they'll have to
> be replaced with regset stuff too.  By using a regset_from_xxx
> function we only need a single entry in the architecture vector,
> instead of three (or even more).

Right.

For the architecture vector, its clear that we already need some sort of 
  regset_from_xxx method that covers all the regsets.  I can imagine it 
being a function parameterized with an ``enum regset_type'', or an array 
variable indexed by the same, or even parameterized with a reggroup (but 
that's getting weird :-).  Which ever.  With this in place we can 
deprecate / eliminate supply_regset et.al..

How much of the thread-db should be done now.  That's MichaelS/MarkKs 
call.  However it is a relatively straight forward task - just lift the 
code from corelow.c.

can we do that?
Andrew