Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@gnu.org>
To: jimb@redhat.com
Cc: cagney@gnu.org, gdb-patches@sources.redhat.com
Subject: Re: RFA: Support libthread_db xregs interface
Date: Thu, 26 Aug 2004 09:40:00 -0000	[thread overview]
Message-ID: <200408260938.i7Q9ceac000020@juw15.nfra.nl> (raw)
In-Reply-To: <vt2oekzkdqc.fsf@zenia.home> (message from Jim Blandy on 25 Aug 2004 00:07:07 -0500)

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

   > > + v:=:int:xregs_size:::0
   > > + v:=:const char *:xregs_name:::0
   > 
   > I gather these were fields in the original xreg_desc object but are
   > missing from the "regset"?  Should these, instead be added to the
   > regset, or a new object extending regset created?

   I was wondering about that, too.  It'd certainly be neater.  Mark,
   what's your take on this?

Fine by me.  The name is certainly useful for printing messages in the
core case too.  The size argument might be useful too, but it should
probably be optional.  There is no use to create an object extending
the regset.  These two should just go in the exitsting regset.

Mark


  reply	other threads:[~2004-08-26  9:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-12 23:39 Jim Blandy
2004-08-23 20:40 ` Andrew Cagney
2004-08-25  5:07   ` Jim Blandy
2004-08-26  9:40     ` Mark Kettenis [this message]
2004-08-27 16:27       ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200408260938.i7Q9ceac000020@juw15.nfra.nl \
    --to=kettenis@gnu.org \
    --cc=cagney@gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jimb@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox