Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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