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
next prev parent 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