Hi Bernhard,

On Tue, 09 Aug 2016 09:55:05 +0200, Heckel, Bernhard wrote:
> I took a look at "p varw" issue.
> 
> >From my point of view, the debug information for  the location of varw is wrong. 
> 
> Set a breakpoint at line 68 and run.
> "P &varw" in GDB gives me same location as the print of "loc(z(2,4,6))" out of the fortran testcase.
> Nevertheless, "loc(varw)" shows me a different location. Investigating on the dwarf debug info, GDB address calculation
> of "varw" is correct. From my point of view, the location expression of "varw" is wrong.
> 
> If you manual examine the content at "loc(varw)" you see the right content.
> 
> FYI: I added a variable "dummy" in subroutine "foo" in order to get the content of fbreg and do manual address calculation. 
> 
> I attached the testcase + dwarf

primarily Fedora 24 GDB (and many Fedora releases back) - with the older Intel
VLA patch series - does PASS the testcase fine with gfortran DWARF so
completely wrong the DWARF is not.

Also you talk here only about starting address of 'varw'.  But that is not
a problem, the starting address in inferior + in GDB do match:
  varw(1, 1, 1) = 6
vs.
$23 = (( ( 6, 5, 1, 5, 5) ( 3, 3, 3, 5, 5) ( 5, 5, 5, 3, 3) ( 3, 5, 5, 5, 5) ) ( ( 5, 3, 3, 3, 5) ( 5, 5, 5, 5, 3) ( 3, 3, 3, 3, 3) ( 3, 3, 3, 3, 3) ) ( ( 3, 3, 3, 3, 3) ( 3, 3, 3, 3, 3) ( 3, 3, 3, 3, 3) ( 3, 3, 3, 3, 3) ) )
(gdb) FAIL: gdb.fortran/dynamic.exp: p varw filled
 - the value 6 is really the first (1,1,1) value printed.
The starting address is nothing special for GDB as starting address is
adjusted/offseted by the inferior caller, GDB just reads the inferior-computed
address.

What is wrong is accessing 'varw' elements not in the first row of the array
by GDB - because GDB needs to know the stride for it.
Stride is described there in DWARF:
    <231>   DW_AT_upper_bound : 11 byte block: 31 97 23 28 6 97 23 20 6 1c 22   (DW_OP_lit1; DW_OP_push_object_address; DW_OP_plus_uconst: 40; DW_OP_deref; DW_OP_push_object_address; DW_OP_plus_uconst: 32; DW_OP_deref; DW_OP_minus; DW_OP_plus)
    <23d>   DW_AT_byte_stride : 6 byte block: 97 23 18 6 34 1e  (DW_OP_push_object_address; DW_OP_plus_uconst: 24; DW_OP_deref; DW_OP_lit4; DW_OP_mul)
and that just fetches the values from gfortran array descriptor - otherwise the
inferior Fortran function 'foo' would not work.

Why do you think gfortran has the DWARF wrong?  Do your GDB patches PASS with
ifort?  I no longer have ifort - I got a license from Markus Metzger many
years ago, it was somehow complicated in Intel to get it for me and the
license laster only one year.  You would have to send me the ifort-built
binary (or .s file).


I have tried now to re-apply a part of the old working Intel VLA patch of
value_subscripted_rvalue():
   unsigned int elt_size = TYPE_LENGTH (elt_type);
-  unsigned int elt_offs = elt_size * longest_to_int (index - lowerbound);
+  unsigned int elt_offs = longest_to_int (index - lowerbound);
+  LONGEST elt_stride = TYPE_BYTE_STRIDE (TYPE_INDEX_TYPE (array_type));
   struct value *v;

+  if (elt_stride > 0)
+    elt_offs *= elt_stride;
+  else if (elt_stride < 0)
+    {
+      int offs = (elt_offs + 1) * elt_stride;
+
+      elt_offs = TYPE_LENGTH (array_type) + offs;
+    }
+  else
+    elt_offs *= elt_size;
+

But it does not work (attached).  Maybe because the stride of an array now
appears to be stored into TYPE_FIELD_BITSIZE of the array itself (not its type)
while with old Intel VLA patchset there was a special field TYPE_BYTE_STRIDE
for that.


Thanks,
Jan