[PATCH] [gdb/tdep] Fix gdb.ada/finish-var-size.exp on ppc64le-linux

[Tom de Vries]

On 5/30/25 14:56, Tom Tromey wrote:
>>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
> 
> Tom> On openSUSE Tumbleweed ppc64le-linux using gcc 14.3.0, with a gdb 16.3 based
> Tom> package and test-case gdb.ada/finish-var-size.exp, I run into:
> Tom> ...
> Tom> (gdb) finish^M
> Tom> Run till exit from #0  pck.get (value=true) at pck.adb:19^M
> Tom> 0x0000000100004a20 in p () at finish-var-size/p.adb:18^M
> Tom> 18        V : Result_T := Get (True);^M
> Tom> Value returned is $1 = <error reading variable: \
> Tom>   Cannot access memory at address 0x0>^M
> Tom> (gdb) FAIL: gdb.ada/finish-var-size.exp: finish
> 
> Thanks for the patch.
> 

Hi Tom,

thanks for the review.

> Tom> Fix this by also checking for valtype->length () != 0.
> 
> Tom> [ I also tested a version of this patch using "!is_dynamic_type (valtype)"
> Tom> instead, but ran into a regression in test-case gdb.ada/variant-record.exp,
> Tom> because type T:
> 
> I talked to Eric about this, and I think the correct test here is
> TYPE_HAS_DYNAMIC_LENGTH.  In finish-var-size.exp, the type does have
> dynamic length -- but in variant-record.exp, Eric points out that while
> the type is dynamic, it has fixed size, which explains the behavior
> you're seeing.
> 
> Looking at other targets, it seems I used TYPE_HAS_DYNAMIC_LENGTH in
> those cases, so I think it would be better to use that here as well.
> 

Committed using the  "!TYPE_HAS_DYNAMIC_LENGTH (valtype)" check.

I've also dropped the bit modifying the clause related to handling of 
small character arrays.

I've spent some time trying to write a test-case to trigger this clause, 
and in the process found out that:
- it's probably a v1 abi thing, in which case the test for that is
   missing, and
- that the clause doesn't trigger for the ada test-case I wrote because
   the char array element type is TYPE_CODE_CHAR instead of
   TYPE_CODE_INT.

I'll submit a separate patch to address these issues.

Thanks,
- Tom

> thanks,
> Tom