On Thursday, November 14 2019, Andrew Burgess wrote:

> Change URL: https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/627
> ......................................................................
>
> gdb/fortran: array stride support
> [...]

Hey Andrew,

I found a problem with this patch, and I'd like to know if you've
noticed this as well.  I first encountered the problem while doing
downstream work on Fedora GDB for Fedora Rawhide; as you are probably
aware, we carry *a lot* of local Fortran VLA patches on Fedora GDB (if
you're not aware about this, feel free to get in touch with me and I'll
be more than happy to explain the situation to you).  However, I am able
to reproduce the problem on upstream GDB as well.

On Fedora GDB, we carry a testcase called gdb.fortran/vla-stride.exp.  I'm
attaching it to this message.  One of its tests fails with:

  (gdb) print pvla
  Cannot access memory at address 0x426000
  FAIL: gdb.fortran/vla-stride.exp: print single-element

See more below.

> diff --git a/gdb/gdbtypes.c b/gdb/gdbtypes.c
> index fd1c765..968aeb2 100644
> --- a/gdb/gdbtypes.c
> +++ b/gdb/gdbtypes.c
[...]
>  /* Create a range type using either a blank type supplied in
>     RESULT_TYPE, or creating a new type, inheriting the objfile from
>     INDEX_TYPE.
> @@ -982,7 +1011,8 @@
>  has_static_range (const struct range_bounds *bounds)
>  {
>    return (bounds->low.kind == PROP_CONST
> -	  && bounds->high.kind == PROP_CONST);
> +	  && bounds->high.kind == PROP_CONST
> +	  && bounds->stride.kind == PROP_CONST);
>  }
>  
>  
> @@ -1189,6 +1219,15 @@
>  	  && !type_not_allocated (result_type)))
>      {
>        LONGEST low_bound, high_bound;
> +      unsigned int stride;
> +
> +      /* If the array itself doesn't provide a stride value then take
> +	 whatever stride the range provides.  Don't update BIT_STRIDE as
> +	 we don't want to place the stride value from the range into this
> +	 arrays bit size field.  */
> +      stride = bit_stride;
> +      if (stride == 0)
> +	stride = TYPE_BIT_STRIDE (range_type);
>  
>        if (get_discrete_bounds (range_type, &low_bound, &high_bound) < 0)
>  	low_bound = high_bound = 0;
> @@ -1198,9 +1237,9 @@
>  	 In such cases, the array length should be zero.  */
>        if (high_bound < low_bound)
>  	TYPE_LENGTH (result_type) = 0;
> -      else if (bit_stride > 0)
> +      else if (stride > 0)
>  	TYPE_LENGTH (result_type) =
> -	  (bit_stride * (high_bound - low_bound + 1) + 7) / 8;
> +	  (stride * (high_bound - low_bound + 1) + 7) / 8;

After spending a lot of time investigating this, I found that the
problem because TYPE_LENGTH (result_type) will be set to a ridiculously
high value here, due to the fact that stride (and therefore bit_stride)
will also be ridiculously high.  bit_stride is obtained back in
gdbtypes.c:resolve_dynamic_array_or_string as:

  ...
  else
    bit_stride = TYPE_FIELD_BITSIZE (type, 0);

TBH, I haven't investigated further because this was taking too long,
and I decided to call on the experts.  The code above was added by Joel,
so I took the liberty to Cc him as well.

The test can be found below.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/