This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/3] fort_dyn_array: Enable dynamic member types inside a structure.
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: "Heckel\, Bernhard" <bernhard dot heckel at intel dot com>
- Cc: Yao Qi <qiyaoltc at gmail dot com>, brobecker at adacore dot com, gdb-patches at sourceware dot org
- Date: Tue, 05 Apr 2016 11:46:43 +0100
- Subject: Re: [PATCH 1/3] fort_dyn_array: Enable dynamic member types inside a structure.
- Authentication-results: sourceware.org; auth=none
- References: <1458204189-13267-1-git-send-email-bernhard dot heckel at intel dot com> <1458204189-13267-2-git-send-email-bernhard dot heckel at intel dot com> <86h9fhpkkz dot fsf at gmail dot com> <570369BC dot 60407 at intel dot com>
"Heckel, Bernhard" <bernhard.heckel@intel.com> writes:
> Actually, when resolving dynamic types I don't use the valaddr. From
> what I understood
> I could even return if valaddr is not Null as the TYPE should already
> be resolved at that time.
> But I was unsure about it and kept the code.
OK, that is a separate issue.
>>
>>> pinfo.next = addr_stack;
>>> TYPE_FIELD_TYPE (resolved_type, i)
>>> @@ -2090,8 +2091,13 @@ resolve_dynamic_struct (struct type *type,
>>> resolved_type_bit_length = new_bit_length;
>>> }
>>> - TYPE_LENGTH (resolved_type)
>>> - = (resolved_type_bit_length + TARGET_CHAR_BIT - 1) / TARGET_CHAR_BIT;
>>> + /* Type length won't change for fortran. Keep what we got from DWARF.
>> Two spaces after ".". Multiple instances of this problem.
>>
>>> + Dynamic fields might change over time but not the struct definition.
>>> + If we would adapt it we run into problems when
>>> + calculating the element offset for arrays of structs. */
>> What is the problem we run into?
> Imagine we have a dynamic allocatable array as a member of a
> structure. The size of the dynamic array can vary over time.
> When we have resolved this allocatable array we don't want to add it's
> length to the structure length it belongs to.
> Dynamic members are not embedded in the structure itself. Only the
> description of the dynamic type is embedded
> and the size of the description (address, bounds,...) won't change.
That is a FORTRAN specific feature. The structure's size changes when the
dynamic array's size changes in C. I am not 100% sure about Ada, but I
suspect it is the same as C in this aspect after I read
https://sourceware.org/ml/gdb-patches/2014-05/msg00522.html
Could you rewrite the comments to say the length of type won't change
for FORTRAN, but the length changes for C (and Ada?).
>>> -
>>> /* Access to the value history. */
>>> /* Record a new value in the value history.
>>> @@ -2416,6 +2428,12 @@ set_internalvar (struct internalvar *var, struct value *val)
>>> call error () until new_data is installed into the var->u to avoid
>>> leaking memory. */
>>> release_value (new_data.value);
>>> +
>>> + /* Internal variables which are created from values with a dynamic location
>>> + don't need the location property of the origin anymore.
>>> + Remove the location property in case it exist. */
>>> + remove_dyn_prop(DYN_PROP_DATA_LOCATION, value_type(new_data.value));
>> Space is needed before "(". What is wrong if we don't do so? Do you
>> have a test case for this?
> An internal variable has it's own valaddr to where the copy is located.
> If we keep the dynamic location from the origin then this
> dyn. location will be used to set
> the value component location.
> As the internal variable is a copy of an value at a certain point in
> time I prefer to get rid off the
> dynamic location attribute then to do some "if else if else"
> constructs when setting the component location.
We remove the dynamic properties from type A for internal variable, but
there is another variable is still using type A. These dynamic
properties can't be found any more. Is it a problem?
> There are tests:
> gdb.fortran/vla-value.exp: print $myvar set to vla1
> gdb.fortran/vla-value.exp: print $myvar(3,6,9)
but they are PASS in mainline.
--
Yao (éå)