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

[Ezra Sitorus <ezra.sitorus@arm.com>]

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?

> 
> 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?

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?

Ezra