From: Paul Schlie <schlie@comcast.net>
To: Steven Johnson <sjohnson@neurizon.net>
Cc: <gdb-patches@sources.redhat.com>
Subject: Re: RFA: Recognize 'x' in response to 'p' packet
Date: Fri, 03 Dec 2004 04:54:00 -0000 [thread overview]
Message-ID: <BDD55BB6.81F4%schlie@comcast.net> (raw)
In-Reply-To: <41AFEC78.50107@neurizon.net>
I would have thought that the BFD etc. description of the target machine
would have correctly identified the register set the machine supported.
(but the desire to support a value of x "un-defined/initialized" may
make sense if interfaced to a simulator, if the value of x were a
represent-able gdb value, and could propagate through expression
evaluations which it presently can't, but would be potentially useful
if it could to catch subtle bugs; but it's not clear that was the intent?)
> From: Steven Johnson <sjohnson@neurizon.net>
>
> The PowerPC is such an example, where the Register response usually
> includes floating point registers, but say the MPC860 family doesnt have
> them. I would imagine the reason to do it is so that, in future, GDB
> can remove from the users view registers that are non existent for a
> target, rather than show them as 0's.
>
> If so, then this would be a necessary first step (identifying such from
> the target.)
>
> Steven
>
> Paul Schlie wrote:
>
>>> Jim Blandy
>>> * remote.c (fetch_register_using_p): Recognize 'x's for the value
>>> of the register as indicating that the register's value is not
>>> available.
>>
>>
>> Out of curiosity, under what practical circumstances would the value of a
>> register not be accessible? (and if not, shouldn't an error be returned, as
>> opposed to an 'x' which is converted to a 0 anyway? Which I've noticed "g"
>> packets also assume?)
next prev parent reply other threads:[~2004-12-03 4:54 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-03 1:29 Paul Schlie
2004-12-03 4:32 ` Steven Johnson
2004-12-03 4:54 ` Paul Schlie [this message]
2004-12-03 13:57 ` Daniel Jacobowitz
2004-12-03 21:48 ` Michael Snyder
2004-12-03 21:45 ` Michael Snyder
2004-12-03 22:53 ` Paul Schlie
2004-12-03 23:44 ` Paul Schlie
-- strict thread matches above, loose matches on Subject: below --
2004-12-03 0:22 Jim Blandy
2004-12-16 21:35 ` Jim Blandy
2004-12-17 22:20 ` Daniel Jacobowitz
2004-12-17 22:45 ` Jim Blandy
2004-12-18 1:24 ` Daniel Jacobowitz
2004-12-21 21:30 ` Jim Blandy
2004-12-23 16:43 ` Jim Blandy
2004-12-23 17:22 ` Daniel Jacobowitz
2004-12-28 13:15 ` Jim Blandy
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=BDD55BB6.81F4%schlie@comcast.net \
--to=schlie@comcast.net \
--cc=gdb-patches@sources.redhat.com \
--cc=sjohnson@neurizon.net \
/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