This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 01/23] dwarf: add dwarf3 DW_OP_push_object_address opcode
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Keven Boell <keven dot boell at linux dot intel dot com>
- Cc: Keven Boell <keven dot boell at intel dot com>, gdb-patches at sourceware dot org, sanimir dot agovic at intel dot com
- Date: Mon, 7 Jul 2014 08:29:53 -0700
- Subject: Re: [PATCH 01/23] dwarf: add dwarf3 DW_OP_push_object_address opcode
- Authentication-results: sourceware.org; auth=none
- References: <1401861266-6240-1-git-send-email-keven dot boell at intel dot com> <1401861266-6240-2-git-send-email-keven dot boell at intel dot com> <20140610095445 dot GA5259 at adacore dot com> <53984AE9 dot 7020200 at linux dot intel dot com> <20140611130815 dot GC4709 at adacore dot com> <53995BFA dot 60109 at linux dot intel dot com> <20140612154729 dot GE4730 at adacore dot com> <53A0470E dot 9050206 at linux dot intel dot com> <20140621152145 dot GA4417 at adacore dot com>
> I'd like to add a function that resolves a value - that way, the work
> is going to be centralized at one place. But I would think that I can
> take care of this independently of your patch series, so you do not
> need to worry about that for this series.
FTR, I gave it a try a few weeks ago being going away for a while,
and found that it was probably not as straightforward as one thought.
Extracting the original value's type and address to create resolved
type is pretty straightforward if you assume that the value address
is always going to be valid if the type uses dynamic properties. But
reconstructing a value from that original value and the new type
seems a lot trickier. If the value has a location, is the location
to be preserved, for instance? I don't want to create a non-lval
value if the original value was an lval. That way, expressions
involving operators such as the address operator still work.
Thoughts?
--
Joel