Re: [RFC PATCH 5/5] gdb/aarch64: Tests for fpmr

[Luis <luis.machado.foss@gmail.com>]

Hi,

On 16/09/2025 12:09, Ezra Sitorus wrote:
> Thanks for this - it's very helpful.
> 
>> Thanks for the patch.
>>
>> On 05/09/2025 14:17, Ezra.Sitorus@arm.com wrote:
>>> From: Ezra Sitorus <ezra.sitorus@arm.com>
>>>
>>> Add tests for FPMR support in gdb/gdbserver. These tests check
>>> availability of FPMR, reading/writing to FPMR and core file generation.
>>>
>>> For these tests, I have used shrinkwrap for FPMR emulation. I am not
>>> sure on how to do these tests properly as there are some things I'm not
>>> sure about:
>>>
>>> * Which board file do I use to test this? I've resorted to adapting
>>>     remote-stdio-gdbserver.exp to use tcp when starting gdbserver
>>>     remotely.
>>
>> If you have Linux running on the FVP, you need to build gdb/gdbserver
>> natively in there or cross-build aarch64-linux versions of gdb/gdbserver ,
>> copy the binaries over and then invoke the testsuite like so:
>>
>> make check-gdb RUNTESTFLAGS="--target_board=native-gdbserver"
>>
>> You'll run gdb's testsuite against gdbserver inside the FVP. It will be
>> fairly slow for sure, but that's unfortunately how it goes.
> 
> Why is it the case that we run gdb + gdbserver? I assume this is less demanding
> than running gdb on its own?

I´d say testing native gdb is a bit lighter. Testing with gdbserver (or 
any remote target really) has a lot more overhead due to the serial 
protocol communication. Also potentially more file transfers between 
gdbserver and gdb.

> 
>>
>> If you want to exercise gdbserver in extended-remote mode, replace
>> native-gdbserver with native-extended-gdbserver.
>>
>>> * Do I need to run the whole regression test? This is quite slow, and
>>>     comes up with a lot of failures.
>>
>> It is a good idea to run the entire testsuite at least once to make sure
>> things didn't break somewhere. If your change is aarch64-specific, it still
>> makes sense to run the entire testsuite (maybe run it on a big server to see
>> if things are still sane), but once you know the code is OK, you can then
>> focus on the gdb.arch/*aarch64*.exp tests.
>>
> 
> Do you know roughly how long this takes? In my case, I've been running for 24
> hours and it's still got a long way to go. Does changing to native-extended-gdbserver
> speed things up?

My experience with QEMU is that it takes less than 24h to run the entire 
thing. But the FVP is slower than that, so I think a couple days or more 
sound reasonable.

Switching to native-extended-gdbserver won´t help unfortunately, as that 
is mostly a different remote target mode.

To speed things up, you could test gdb/gdbserver on a regular AArch64 
machine and then go do the gdb.arch/aarch64*.exp tests on the FVP. Given 
the FPMR changes are fairly localized, the risk of breaking things is low.

> 
> On another note, I looked at the 'Testing gdbserver in a remote cross-target
> configuration' section in the TestingGDB page in GDB Wiki. Would this be a
> viable option? Unlike last time where I rewrote core_find for example, would
> this help out as it delegates compiling to the build system (if I've understood
> correctly)? Or should I just keep it simple with native-gdbserver/native-extended-gdbserver?

Running gdb on the host and connecting to gdbserver on the target is 
definitely faster, but you need the board files to handle all the logic 
to spawn the emulator for each test (if in user mode) or spawn the 
emulator and connect to it and then spawn gdbserver for every test.

I don´t think we have such a board file. That's usually a custom 
implementation.

> 
> Ezra