[PATCH] dwarf2: Fix dwarf stack fetch array view size mismatch

[Denis Lukianov]

On Fri, 2022-08-19 at 20:55 -0400, Simon Marchi wrote:
> 
> I don't understand what you are saying.  All I can see is that the
> source array_view size will be of the length of subobj_type: we call
> slice with length == len, where len is `TYPE_LENGTH (subobj_type)`. 
> And
> the destination array_view size is also of the length of subobj_type:
> retval was allocated as `allocate_value (subobj_type)`, so its
> contents
> are of the length of subobj_type.
> 

I know nothing about gdb internals, just reading code in the file:

copy (value_contents_all (val).slice (subobj_offset, len),
		  value_contents_raw (retval));

We know val is allocated to be the length of subobj_type.
We know retval is allocated to be the length of subobj_type.
We know len is the length of subobj_type.
We know slice only gives a view same size or smaller.

So, the source array_view length must be len - subobj_offset.

Therefore source array_view size will be of the length of subobj_type
and match the destination only in the event that subobj_offset happens
to be zero. The line above does not guarantee it:

subobj_offset += n - max;

So it looks broken for big endian systems. And maybe any subtype that
is not the first element of a type on the others.