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: Thu, 12 Jun 2014 09:51:22 +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>
> I understand this part, but the main part of my question is about
> the fact that, most of the time, we manipulate "struct value" objects,
> which may not represent addressable entities. For instance, let's say
> I have a struct value whose type is a TYPE_CODE_ARRAY. If I need to
> resolve the value's type, how should I be doing it? Perhaps, the
> question in itself suggest the introduction of a function that would
> take a value, and returned a value whose time is resolved?
>
But this would still require the address to be communicated to the
property evaluation functions as the type still needs to be resolved
using resolve_dynamic_type. Usually resolve_dynamic_type will be called
through value_from_contents_and_address, which generates you a resolve
type in a value object. Do you have a concrete Fortran code example,
where you think the current implementation might go wrong?
Keven