Hi, Got it! I have sent over an updated version that avoids the int cast and associated checks for an appropriate gdb version.
Thanks, Vacha On Tue, Sep 9, 2025 at 4:55 AM Peter Maydell <peter.mayd...@linaro.org> wrote: > On Mon, 8 Sept 2025 at 19:32, Vacha Bhavsar > <vacha.bhav...@oss.qualcomm.com> wrote: > > > >So the only difference between these two branches is that we are > > >checking "int(v) == MAGIC" rather than "v == MAGIC" ? > > > > > > > > >Is this a "one GDB only works one way, and the other GDB only > > >works the other way" case? Or is there a real interesting thing > > >we'd like to test involving the cast ? > > > Yes, the only difference between the two branches is the presence > > of the int cast. This seems to be an issue limited to specific versions > > > > of gdb. This has been discussed with the gdb team > > (https://sourceware.org/pipermail/gdb/2025-August/051868.html, > > https://sourceware.org/pipermail/gdb/2025-August/051878.html) and > > a bug has been filed. With additional tests I have found that the > > int cast causes no issues with the testcase when running gdb16.1 > > or newer. Other than this issue there is no intention on our end > > of testing anything interesting regarding casting as the int cast > > was included to stay aligned with the existing SVE test. > > So if we can test QEMU's gdbstub functionality by writing > the test in a way that avoids the int cast and which doesn't > lose coverage, we should just do that. That would mean > we don't need to have checks for whether the gdb can do > the cast and multiple paths through the test code. > > -- PMM >
