This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/19893] Synthetic pointers created from C++ references are broken


https://sourceware.org/bugzilla/show_bug.cgi?id=19893

--- Comment #9 from Pedro Alves <palves at redhat dot com> ---
(In reply to Martin Galvan from comment #8)
> Oh, I see. Should I push the new branch to origin, or keep it on a separate
> (e.g. GitHub) repo?

If by your remote named "origin" is sourceware.org, then yes, that's fine. 
Just be sure to name the branch "users/$yourname/$whatever".

> > Perhaps we should be making a copy of the value before calling
> > indirect_pieced_value ?  How do other coerce_ref implementations handle this?
> 
> Incidentally, value_copy also takes a non-const argument because it calls
> value_contents_all_raw on the value it's passed.

  if (!value_lazy (val))
    {
      memcpy (value_contents_all_raw (val), value_contents_all_raw (arg),
              TYPE_LENGTH (value_enclosing_type (arg)));

    }

The only thing value_contents_all_raw does is make sure there's a value
contents buffer allocated.  But since we know "val" isn't lazy,
we know we already have a contents buffer.  So that could well be changed to
read:

  if (!value_lazy (val))
    {
      gdb_assert (arg->contents != NULL);
      memcpy (value_contents_all_raw (val), arg->contents,
              TYPE_LENGTH (value_enclosing_type (arg)));

    }

> 
> AFAIK the only struct lval_funcs that actually implements coerce_ref is
> entry_data_value_funcs. It uses the computed location's "closure", which for
> entry_data is itself a value. For pieced_value, the closure is a struct
> piece_closure, which for synthetic pointers has only one piece. That 'piece'
> in turn has the DIE/offset info required to fetch the referenced value from
> memory.  I'm using indirect_pieced_value precisely because it knows how to
> interpret that info and fetch the value.

So can't we split indirect_pieced_value in two, around the
extract_signed_integer / value_contents call ?

That is, make the second half of indirect_pieced_value be a helper function
that takes a byte_offset and a piece (etc. as needed) as parameters, and then
have indirect_pieced_value use value_contents to get at the offset, and have
coerce_ref use value_content_for_printing_const to get at the offset.  Since
synthetic pointers only have one piece, it should be simple to get at it
without the complicated loop at the top of indirect_pieced_value, I'd assume.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]