Re: [V4 00/21] Fortran dynamic array support

[Bernhard Heckel <bernhard dot heckel at intel dot com>]

On 25/08/2016 19:06, Jan Kratochvil wrote:
> On Tue, 23 Aug 2016 15:34:09 +0200, Bernhard Heckel wrote:
> > created a branch with all stride patches.
> users/bheckel/fortran-strides
> 2c392d41a3f2e38deeb9db5b7a93ca45682bbe3b
>
> > I don't see regression on RH7.1, gcc 4.8.3-9
> I see a regression for 32-bit targets (x86_64-m32 or native i686)
> on Fedora 24 (gcc-gfortran-6.1.1-3.fc24.x86_64).  I do not see the regression
> on CentOS-7.2 (x86_64-m32).
>
> print pvla^M
> value requires 4294967288 bytes, which is more than max-value-size^M
> (gdb) FAIL: gdb.fortran/vla-stride.exp: print single-element
>
> I have attached a fix.
>
> It is because:
>      <115>   DW_AT_lower_bound : 4 byte block: 97 23 10 6        (DW_OP_push_object_address; DW_OP_plus_uconst: 16; DW_OP_deref)
>      <11a>   DW_AT_upper_bound : 4 byte block: 97 23 14 6        (DW_OP_push_object_address; DW_OP_plus_uconst: 20; DW_OP_deref)
>      <11f>   DW_AT_byte_stride : 6 byte block: 97 23 c 6 34 1e   (DW_OP_push_object_address; DW_OP_plus_uconst: 12; DW_OP_deref; DW_OP_lit4; DW_OP_mul)
> 	DW_AT_lower_bound == 1
> 	DW_AT_upper_bound == 1
> 	DW_AT_byte_stride == (-2) * 4 == -8
>
> I am not sure if gfortran is really wrong or not but a stride does not make
> sense for me for a single row array.
>
> Attaching also gdb.fortran/vla-stride.f90 from your branch built with
> gcc-gfortran-6.1.1-3.fc24.x86_64 on Fedora 24 x86_64 in -m32 mode.
>
> Besides that I see on all archs
> 	-FAIL: gdb.pascal/arrays.exp: Print dynamic array of string
> 	+FAIL: gdb.pascal/arrays.exp: Print dynamic array of string (GDB internal error)
> but that testcase is only in Fedora and the Pascal (fpc) support has been not
> well maintained so far so I am OK with that.
>
>
> Thanks,
> Jan
Hi Jan,

found the root cause of the issue on 32bit inferior.
According to DWARF4 (Page 100) strides can be negative but evaluation of 
dynamic properties in GDB is done via CORE_ADDR which is unsigned.
This causes the issue that the type length seems to be way to big.

The following code is not claimed to be a fix, just want to point you to 
the right direction.
In gdbtypes.c:
  prop = &TYPE_RANGE_DATA (dyn_range_type)->stride;
  if (dwarf2_evaluate_property (prop, NULL, addr_stack, &value))
    {
      /* if target is 32bit, execute next if clause  */
      if (value > (2^31))
    value += 2^32;

      stride.kind = PROP_CONST;
      stride.data.const_val = value;
    }
Also, in dwarf2read.c all DW_AT_...STRIDE 's are handles as unsigned. 
This has to be fixed as well.

I will investigate more on the stride topic next week.


Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928