Running testsuite on QEMU (sorry if possible duplicate)

[Konstantin Vladimirov]

Hi,

>  Are you using a remote target test setup, where the testsuite starts a gdbserver in the VM and GDB runs on the (e.g. x86-64) host?

Exactly this case.

> This would be a mistake, it would need to be fixed

Thanks, then we will fix such cases locally and send some patches to
the upstream.

---
With best regards, Konstantin

On Fri, Sep 23, 2022 at 5:51 PM Simon Marchi <simark@simark.ca> wrote:
>
>
>
> On 2022-09-22 06:31, Konstantin Vladimirov via Gdb wrote:
> > Hi,
> >
> > My colleague Ivan already sent this question to this mailing list, but
> > it looks like his email hasn't landed.
> >
> > We are trying to run dejagnu/gdb testsuite on QEMU (RISCV) on Linux.
> > Some tests that pass on the local machine fail as they expect having
> > shared libs or other binary files at hardcoded paths on a machine
> > (QEMU in our case) where the binary is running.
> >
> > Question is: is it ok to patch gdb testsuite to get rid of hardcoded
> > paths. Or maybe this is something intentional?
> >
> > Example: gdb.base/print-file-var.exp, see SHLIB_NAME variable.
>
> Can you clarify what is your setup?
>
> Are you using a remote host test setup?  This would mean that you
> cross-compile and "make check" on your host (e.g. your x86-64 machine),
> but the testsuite uploads the gdb binary in the VM and runs it there.
> And GDB itself would debug the local system natively (in the VM).
>
> Or, are you using a remote target test setup, where the testsuite starts
> a gdbserver in the VM and GDB runs on the (e.g. x86-64) host?
>
> Either way, it sounds like that test you mention would be broken either
> way, as SHLIB_NAME would be a path on the host.  This would be a
> mistake, it would need to be fixed.  Not many people are using remote
> host/target test setups, so these mistakes tend to creep in a lot.
>
> Simon