This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 02/23] dwarf: add DW_AT_data_location support
- From: Keven Boell <keven dot boell at linux dot intel dot com>
- To: Joel Brobecker <brobecker at adacore dot com>, Keven Boell <keven dot boell at intel dot com>
- Cc: gdb-patches at sourceware dot org, sanimir dot agovic at intel dot com, Tom Tromey <tromey at redhat dot com>
- Date: Wed, 11 Jun 2014 14:29:32 +0200
- Subject: Re: [PATCH 02/23] dwarf: add DW_AT_data_location support
- Authentication-results: sourceware.org; auth=none
- References: <1401861266-6240-1-git-send-email-keven dot boell at intel dot com> <1401861266-6240-3-git-send-email-keven dot boell at intel dot com> <20140610121014 dot GA6480 at adacore dot com>
Hi Joel,
I've addressed your comments and the changes will be part of patch series v2.
Keven
> Hello,
>
>> An object might have a descriptor proceeding the actual value.
>> To point the debugger to the actually value of an object
>> DW_AT_data_location is used for. For example the compile may
>> emit for this entity:
>>
>> 1| int foo[N];
>>
>> the following descriptor:
>>
>> struct array {
>> size_t size;
>> void* data; // DW_AT_data_location describes this location
>> }
>>
>> This allows GDB to print the actual data of an type.
>>
>> 2014-05-28 Sanimir Agovic <sanimir.agovic@intel.com>
>> Keven Boell <keven.boell@intel.com>
>>
>> * dwarf2read.c (set_die_type): Parse and save DW_AT_data_location
>> attribute.
>> * gdbtypes.c (is_dynamic_type): Consider a type being dynamic if
>> the data location has not yet been resolved.
>> (resolve_dynamic_type): Evaluate data location baton
>> if present and save its value.
>> * gdbtypes.h <main_type>: Add data_location.
>> (TYPE_DATA_LOCATION): New macro.
>> (TYPE_DATA_LOCATION_ADDR): New macro.
>> (TYPE_DATA_LOCATION_IS_ADDRESS): New macro.
>> * value.c: Include dwarf2loc.h.
>> (value_fetch_lazy): Use data location addres to read value from
>> memory.
>> (coerce_ref): Construct new value from data location.
>
> Here are some comments and questions, but it would be nice, IMO, if
> the patch was also reviewed by Tom, particularly since it introduces
> a new field in struct main_type, which is a size-sensitive, I think.
>
> Also, it would be nice if you could include a copy of the actual
> DWARF output in the revision log of your patch, for easy reference
> of what you're trying to support.
>
>> diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
>> index 6ebfffc..7a0f7f4 100644
>> --- a/gdb/dwarf2read.c
>> +++ b/gdb/dwarf2read.c
>> @@ -21499,6 +21499,7 @@ set_die_type (struct die_info *die, struct type *type, struct dwarf2_cu *cu)
>> {
>> struct dwarf2_per_cu_offset_and_type **slot, ofs;
>> struct objfile *objfile = cu->objfile;
>> + struct attribute *attr;
>>
>> /* For Ada types, make sure that the gnat-specific data is always
>> initialized (if not already set). There are a few types where
>> @@ -21513,6 +21514,20 @@ set_die_type (struct die_info *die, struct type *type, struct dwarf2_cu *cu)
>> && !HAVE_GNAT_AUX_INFO (type))
>> INIT_GNAT_SPECIFIC (type);
>>
>> + /* Read DW_AT_data_location and set in type. */
>> + attr = dwarf2_attr (die, DW_AT_data_location, cu);
>> + if (attr_form_is_block (attr))
>
> Here (in set_die_type), why do you limit the processing the block-form
> data_location attributes? Why not just call attr_to_dynamic_prop
> regardless of the form, and let that function deal with whatever
> the form is? In other words, trop the form check and just keep
> the following bit:
>
>> + struct dynamic_prop prop;
>> +
>> + if (attr_to_dynamic_prop (attr, die, cu, &prop))
>> + {
>> + TYPE_DATA_LOCATION (type)
>> + = obstack_alloc (&objfile->objfile_obstack, sizeof (prop));
>> + *TYPE_DATA_LOCATION (type) = prop;
>> + }
Good catch, there is no reason to limit the processing here.
>
>> --- a/gdb/gdbtypes.c
>> +++ b/gdb/gdbtypes.c
>> @@ -1635,8 +1635,12 @@ is_dynamic_type (struct type *type)
>> or the elements it contains have a dynamic contents. */
>> if (is_dynamic_type (TYPE_INDEX_TYPE (type)))
>> return 1;
>> - else
>> - return is_dynamic_type (TYPE_TARGET_TYPE (type));
>> + else if (TYPE_DATA_LOCATION (type) != NULL
>> + && (TYPE_DATA_LOCATION_KIND (type) == PROP_LOCEXPR
>> + || TYPE_DATA_LOCATION_KIND (type) == PROP_LOCLIST))
>> + return 1;
>> + else
>> + return is_dynamic_type (TYPE_TARGET_TYPE (type));
>
> The comment needs to be updated. Your change is also splitting
> the "if bounds or contents is dynamic" logic. Perhaps you could
> simply add the data-location check at the start of the function
> with a command that says: A type which has a data_location which
> [bla bla] is a dynamic type
I've updated the comment.
>
>
>> + type = resolved_type;
>> +
>> + /* Resolve data_location attribute. */
>> + prop = TYPE_DATA_LOCATION (type);
>> + if (dwarf2_evaluate_property (prop, addr, &value))
>> + {
>> + TYPE_DATA_LOCATION_ADDR (type) = value;
>> + TYPE_DATA_LOCATION_KIND (type) = PROP_CONST;
>> + }
>> + else
>> + TYPE_DATA_LOCATION (type) = NULL;
>
> Here, I do not understand why you override TYPE, instead of just
> using RESOLVED_TYPE directly.
I did this for improving the readability, however maybe this is just confusing. I changed it.
>
>> @@ -722,6 +722,10 @@ struct main_type
>>
>> struct func_type *func_stuff;
>> } type_specific;
>> +
>> + /* * Indirection to actual data. */
>> +
>> + struct dynamic_prop *data_location;
>
> I'd like to have a comment which is a little more descriptive of
> what this field contains. Someone who reads this comment should be
> able to understand it without having to grep for this field to
> get an idea of how this field is used.
Done.
>
>> +/* Attribute accessors for VLA support. */
>
> I think this comment is too specific. Although this field is
> instroduced to support VLAs, descriptors can probably be used
> in other contexts. I don't think you really need a comment,
> in this case, though.
Done.
>
>> +#define TYPE_DATA_LOCATION(thistype) \
>> + TYPE_MAIN_TYPE(thistype)->data_location
>> +#define TYPE_DATA_LOCATION_BATON(thistype) \
>> + TYPE_DATA_LOCATION (thistype)->data.baton
>> +#define TYPE_DATA_LOCATION_ADDR(thistype) \
>> + TYPE_DATA_LOCATION (thistype)->data.const_val
>> +#define TYPE_DATA_LOCATION_KIND(thistype) \
>> + TYPE_DATA_LOCATION (thistype)->kind
>> +
>> /* Moto-specific stuff for FORTRAN arrays. */
>>
>> #define TYPE_ARRAY_UPPER_BOUND_IS_UNDEFINED(arraytype) \
>> diff --git a/gdb/value.c b/gdb/value.c
>> index d125a09..1c88dfd 100644
>> --- a/gdb/value.c
>> +++ b/gdb/value.c
>> @@ -3635,8 +3635,14 @@ value_fetch_lazy (struct value *val)
>> }
>> else if (VALUE_LVAL (val) == lval_memory)
>> {
>> - CORE_ADDR addr = value_address (val);
>> struct type *type = check_typedef (value_enclosing_type (val));
>> + CORE_ADDR addr;
>> +
>> + if (TYPE_DATA_LOCATION (type) != NULL
>> + && TYPE_DATA_LOCATION_KIND (type) == PROP_CONST)
>> + addr = TYPE_DATA_LOCATION_ADDR (type);
>> + else
>> + addr = value_address (val);
>
> I am wondering if this part shouldn't be in value_address itself.
> WDYT? Tom?
>
>>
>> if (TYPE_LENGTH (type))
>> read_value_memory (val, 0, value_stack (val),
>> --
>> 1.7.9.5
>