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: Keven Boell <keven dot boell at linux dot intel dot com>
- To: Joel Brobecker <brobecker at adacore 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: Tue, 17 Jun 2014 15:47:58 +0200
- 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>
> I think we're talking past each other :-(, so I'll try to explain
> in more details what I have in mind.
Yes, I think so, sorry for that :(
>
> I do not have any concrete Fortran example for you, and I am not
> saying that the implementation is wrong. I am asking a question
> of how things should work if the object you are trying to evaluate
> and resolve actually does not live in memory. If the object does
> not live in memory (eg: lives in register), are we stuck? The answer
> might be yes, or maybe that's something that can't happen, but I would
> like to explore that question to have a better understanding of what
> we can expect to achieve.
We tried to follow the DWARF standard to get this implemented. The DWARF
standard says that this scenario cannot happen in combination with the
DW_OP_push_object_address operation:
"The DW_OP_push_object_address operation pushes the _address_ of the
object currently being evaluated as part of evaluation of a user presented
expression [...] This operator provides explicit functionality (especially
for arrays involving descriptors) that is analogous to the implicit push
of the base address of a structure prior to evaluation of a
DW_AT_data_member_location to access a data member of a structure."
DWARF Debugging Information Format, Version 4.
So I think having only the address here seems to be ok.
>
> Ideally, I have a feeling that what we should be taking isn't
> an address, but a struct value. The struct value object carries
> much more information, and might allow us to deal with the case
> above. Another interesting, and perhaps more likely scenario, is
> the case where part of the object is optimized out. You can't
> expect a "contents and address" to represent accurately your object,
> so chances are GDB would get it wrong.
I agree with you that having a struct value instead of an address gives
more flexibility, but for now I think this is not required according to
the DWARF standard. If there is a real-world use-case where a full struct
value object is required instead of having only the address, then this
functionality can be added after this patch series.
The patch series has been outdated, due to the introduction of two
new functions by Tom (resolve_dynamic_struct and resolve_dynamic_union).
Shall I therefore submit version 2?
Keven