public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: drow@false.org
Cc: gdb@sourceware.org
Subject: Re: RFC: Available registers as a target property
Date: Sat, 07 May 2005 16:04:00 -0000	[thread overview]
Message-ID: <200505071603.j47G3tuc030771@elgar.sibelius.xs4all.nl> (raw)
In-Reply-To: <20050506162029.GA30792@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 6 May 2005 12:20:29 -0400)

Hi Daniel,

Your proposal sounds reasonable to me.  Do I understand correctly that
the "set" keyword is supposed to be used to specify the contents of
the `g' packet, or is there a somewhat broader use for them?

Anyway, here are some random thoughts about things we might need to
consider.  It's a bit i386 centric, the issues mostly are not.

* Is this going to allow us to make changes freely to the internal
  layout of GDB's register cache?

* How will we treat registers that the user might reasonably expect to
  be there, but aren't made available by the target?

FreeBSD/i386 for example still has no way to get at the SSE registers,
but has no problem executing code that uses its registers.  What do we
do when the user says "print $xmm0" when connected to a FreeBSD/i386
target?  Do we print:

(gdb) p $xmm0
$1 = void

or are we going to try to print a more helpful message for
well-known-but-unavailable registers?

* What do we do with pseudo registers?

The ia32 MMX registers are optional pseudo registers; they reinterpret
the floating-point registers in a particular way.  As such they won't
be transmitted between the target and GDB.  Yet it would be nice if we
had a mechanism for the target to indicate whether MMX is available
such that GDB knows if it should display the MMX registers or not.

* How does this interact with register groups?

Do we need a mechanism to indicate the register group to which a
register belongs, or is the default register group behaviour good
enough?


Mark

  parent reply	other threads:[~2005-05-07 16:04 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-06 16:20 Daniel Jacobowitz
2005-05-07 10:25 ` Eli Zaretskii
2005-05-07 16:19   ` Daniel Jacobowitz
2005-05-07 19:37     ` Eli Zaretskii
2005-05-09 15:37       ` Daniel Jacobowitz
2005-05-09 20:58         ` Eli Zaretskii
2005-05-07 16:04 ` Mark Kettenis [this message]
2005-05-09 16:20   ` Daniel Jacobowitz
2005-05-09 15:57 ` Paul Brook
2005-05-09 16:32   ` Daniel Jacobowitz
2005-05-09 21:33 ` Chris Zankel
2005-05-09 23:07   ` Daniel Jacobowitz
2005-05-10  0:23     ` Chris Zankel
2005-05-10 21:08       ` Daniel Jacobowitz
2005-05-12 23:35         ` Chris Zankel
2005-05-17 14:03           ` Daniel Jacobowitz
2005-05-10  0:54 ` Ramana Radhakrishnan
2005-05-10 21:14   ` Daniel Jacobowitz
2005-05-17 19:32 ` Daniel Jacobowitz
2005-05-18  9:29   ` Richard Earnshaw
2005-05-19  1:00     ` Daniel Jacobowitz
2005-05-20 14:54       ` Richard Earnshaw
2005-05-09 22:39 Paul Schlie
2005-05-10  0:03 Paul Schlie
2005-05-10 11:12 Paul Schlie
2005-05-17 23:08 Paul Schlie

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=200505071603.j47G3tuc030771@elgar.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=drow@false.org \
    --cc=gdb@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).