From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: tromey@redhat.com (Tom Tromey)
Cc: drow@false.org (Daniel Jacobowitz), gdb-patches@sourceware.org
Subject: Re: RFC: partially available registers
Date: Thu, 21 Jul 2011 05:23:00 -0000 [thread overview]
Message-ID: <201107202102.p6KL2mAq030051@d06av02.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <m3y5zsyajz.fsf@fleche.redhat.com> from "Tom Tromey" at Jul 20, 2011 02:14:08 PM
Tom Tromey wrote:
> 2011-07-20 Tom Tromey <tromey@redhat.com>
>
> * amd64-tdep.c (amd64_pseudo_register_read_into_value): Rename
> from amd64_pseudo_register_read. Change arguments. Call
> mark_value_bytes_unavailable when needed.
> (amd64_init_abi): Use set_gdbarch_pseudo_register_read_value, not
> set_gdbarch_pseudo_register_read.
> * sentinel-frame.c (sentinel_frame_prev_register): Use
> regcache_cooked_read_into_value.
> * regcache.h (regcache_cooked_read_into_value): Declare.
> * regcache.c (regcache_cooked_read_into_value): New function.
> (regcache_cooked_read): Call
> gdbarch_pseudo_register_read_into_value if available.
> * i386-tdep.h (i386_pseudo_register_read_into_value): Declare.
> (i386_pseudo_register_read): Remove.
> * i386-tdep.c (i386_pseudo_register_read_into_value): Rename from
> i386_pseudo_register_read. Change arguments. Call
> mark_value_bytes_unavailable when needed.
> (i386_gdbarch_init): Call
> set_gdbarch_pseudo_register_read_into_value, not
> set_gdbarch_pseudo_register_read.
> * gdbarch.sh (pseudo_register_read_into_value): New method.
> * gdbarch.c, gdbarch.h: Rebuild.
> * findvar.c (value_from_register): Call get_frame_register_value.
I'm not completely happy about the "read into value" style interface;
this leaves unclear just how the value passed into that interface is
supposed to have been set up. Should the callback have to cope with
different types (or even lengths), value offset, or more complex
value properties like enclosing type? Apparently not -- the actual
callback implementations of your don't attempt to with (or even
check for!) any of that, they just blindly assume the value has been
set up as they expect.
I'd prefer an interface that simply *returns* a value, which then the
callback would be free to set up as desired. This would also be much
more in line with all the other interfaces that produce values ...
> @@ -647,14 +647,16 @@ value_from_register (struct type *type, int regnum, struct frame_info *frame)
> else
> {
> int len = TYPE_LENGTH (type);
> + struct value *v2;
>
> /* Construct the value. */
> v = gdbarch_value_from_register (gdbarch, type, regnum, frame);
>
> /* Get the data. */
> - ok = get_frame_register_bytes (frame, regnum, value_offset (v), len,
> - value_contents_raw (v),
> - &optim, &unavail);
> + v2 = get_frame_register_value (frame, regnum);
> +
> + value_contents_copy (v, 0, v2, 0, len);
> + ok = 1;
> }
This seems to introduce a bug by ignoring value_offset (v).
If v is of a smaller type than the full register width, only
the appropriate bytes of v2 (which do not always start at the
beginning, in particular on big-endian machines) ought to be
copied over to v.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
next prev parent reply other threads:[~2011-07-20 21:03 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-13 20:17 Tom Tromey
2011-07-14 4:24 ` Daniel Jacobowitz
2011-07-15 20:52 ` Tom Tromey
2011-07-18 4:15 ` Daniel Jacobowitz
2011-07-20 20:14 ` Pedro Alves
2011-07-20 18:49 ` Sergio Durigan Junior
2011-07-20 20:46 ` Tom Tromey
2011-07-20 20:53 ` Tom Tromey
2011-07-24 13:48 ` Mark Kettenis
2011-07-25 15:50 ` Tom Tromey
2011-07-21 5:23 ` Ulrich Weigand [this message]
2011-07-21 20:27 ` Tom Tromey
2011-07-22 13:48 ` Ulrich Weigand
2011-07-22 15:42 ` Tom Tromey
2011-07-22 14:30 ` Pedro Alves
2011-07-22 15:40 ` Tom Tromey
2011-07-22 19:10 ` Pedro Alves
2011-07-22 19:19 ` Tom Tromey
2011-07-22 19:31 ` Pedro Alves
2011-07-22 21:58 ` Pedro Alves
2011-07-22 22:20 ` Tom Tromey
2011-07-26 17:08 ` Pedro Alves
2011-07-26 17:13 ` Pedro Alves
2011-07-26 19:46 ` Tom Tromey
2011-07-27 18:25 ` Tom Tromey
2011-07-27 19:30 ` Tom Tromey
2011-07-27 19:33 ` Pedro Alves
2011-07-28 5:19 ` Mark Kettenis
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=201107202102.p6KL2mAq030051@d06av02.portsmouth.uk.ibm.com \
--to=uweigand@de.ibm.com \
--cc=drow@false.org \
--cc=gdb-patches@sourceware.org \
--cc=tromey@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