From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: drow@false.org (Daniel Jacobowitz)
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC 1/5] Lazy register values
Date: Fri, 04 Apr 2008 19:29:00 -0000 [thread overview]
Message-ID: <200804041917.m34JHcNk029476@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <20080331220656.GA22012@caradoc.them.org> from "Daniel Jacobowitz" at Mar 31, 2008 06:06:56 PM
Hi Dan,
> This patch allows a register value to be lazy. Lazy register values
> are created by value_of_register_lazy and fetched by value_fetch_lazy,
> like lazy memory values. I went through every check of value_lazy and
> updated the ones which assumed this implied memory; the others guard
> calls to value_fetch_lazy, which is still correct.
I like this approach! However, I'm wondering about some of the
value_lazy changes; for example in code like:
v = allocate_value (elt_type);
if (value_lazy (array))
set_value_lazy (v, 1);
else
memcpy (value_contents_writeable (v),
value_contents (array) + elt_offs, elt_size);
if (VALUE_LVAL (array) == lval_internalvar)
VALUE_LVAL (v) = lval_internalvar_component;
else
VALUE_LVAL (v) = VALUE_LVAL (array);
VALUE_ADDRESS (v) = VALUE_ADDRESS (array);
VALUE_REGNUM (v) = VALUE_REGNUM (array);
VALUE_FRAME_ID (v) = VALUE_FRAME_ID (array);
set_value_offset (v, value_offset (array) + elt_offs);
(in value_subscripted_rvalue), it doesn't seem right to simply
change the if to
if (VALUE_LVAL (array) == lval_memory && value_lazy (array))
If that function were ever called with a lazy register value,
the "else" part would copy from value_contents of that lazy
value, which is actually undefined.
In fact, it would appear that not changing the if at all might
be the correct solution anyway: the new value would then be
marked as lazy register value with offset.
Of course, that would then require that value_fetch_lazy
allows and handles offsets for lazy register values.
I've read through the rest of the patches in this series,
and they look fine to me. I'd be happy to convert any of
the platforms I have access to (s390, ppc, spu, ia64).
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:[~2008-04-04 19:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-31 22:11 Daniel Jacobowitz
2008-04-04 19:29 ` Ulrich Weigand [this message]
2008-04-04 22:06 ` Daniel Jacobowitz
2008-04-04 23:00 ` Ulrich Weigand
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=200804041917.m34JHcNk029476@d12av02.megacenter.de.ibm.com \
--to=uweigand@de.ibm.com \
--cc=drow@false.org \
--cc=gdb-patches@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