Re: [PATCH 0/4] gdb/aarch64: record/replay support for AArch64

[Thiago Jung Bauermann <thiago.bauermann@linaro.org>]

Hello,

Guinevere Larsen <guinevere@redhat.com> writes:

> On 4/20/26 6:52 PM, Ezra.Sitorus@arm.com wrote:
>> From: Ezra Sitorus <ezra.sitorus@arm.com>
>>
>> This patch series enables record/replay for the following AArch64
>> features:
>> * FEAT_LRCPC3 (+rcpc3)
>> * FEAT_CSSC (+cssc)
>> * FEAT_RPRFM (+rprfm)
>> * FEAT_LSE128 (+lse128)

Great!

>> These were tested either with QEMU or Shrinkwrap. In both cases, I seem
>> to have test failures that are not related to my patches (gdb.threads,
>> gdb.mi tests for example). In these cases, is it fair to ignore these?
>> Or is there some underlying issue I've missed?
>
> gdb.threads tests are pretty often unreliable (we usually call them racy, as in, failing
> due to race conditions), and unfortunately some tests consistently fail on some
> configurations. My general recommendation while you're getting used to the tests is to run
> the testsuite before and after your changes, so you have a feel for what is likely to be a
> regression of yours or not.
>
> For reference, my system usually shows 4 failures, but can go up to 6 depending on what I
> do. If I run it with clang, I can expect between 50 and 70 failures.

Yes, a number of gdb.threads tests are flaky. With Linux's ptrace
syscall and the /proc/<pid>/tasks/<tid>/ interfaces that GDB has to work
with, it's hard to make GDB have a race-free accurate view of the
inferior threads. For a glimpse of some of the issues, see for example
bugs 26286¹ and 31832².

Regarding the flaky MI tests, I didn't dig much into them but at least
for some I think the problem is that they generate a lot of output which
can overflow Expect's buffer.

The Linaro CI keeps an "expected failures" file containing the baseline
failures and automatically detected flaky failures. For example:

http://54.172.246.49:9090/jobs/tcwg_gdb_check--master-aarch64-build/builds/10102/archive/artifacts/sumfiles/xfails.xfail

(We're currently doing some server migration so the URL above is likely
 to change at some point. CI notification emails will have the current
 one.)

You can use it with GCC's
contrib/testsuite-management/validate_failures.py script to filter the
noise:

$ validate_failures.py --manifest=xfails.xfail --results=gdb.sum > failures.txt

Note that strictly speaking, the baseline failures are specific of the
machine the CI jobs run on. If you want to be precise you can replace
the "known failures" section of the file with the failures from your
testsuite run of the patch's base commit.

>> In addition, whenever I used QEMU, I disabled gcs because it seems to
>> cause test failures - address/memory accesses seem to always cause a
>> fault. Am I doing something wrong?
>
> Unfortunately I can't help here, never tried running reverse tests on QEMU...

I see those failures too. When I worked on GCS support for GDB, QEMU
didn't have GCS support itself so I was never able to run the whole
testsuite with GCS enabled. It seems I chose too small a set of tests to
run on Shrinkwrap. I'll work on these regressions in the near future.

> I'll try to review your patches tomorrow, to get this moving :)

Thank you! I'm reviewing them too.

-- 
Thiago

¹ https://sourceware.org/bugzilla/show_bug.cgi?id=26286
² https://sourceware.org/bugzilla/show_bug.cgi?id=31832