* Running testsuite on QEMU (sorry if possible duplicate) @ 2022-09-22 10:31 Konstantin Vladimirov 2022-09-23 14:51 ` Simon Marchi 0 siblings, 1 reply; 3+ messages in thread From: Konstantin Vladimirov @ 2022-09-22 10:31 UTC (permalink / raw) To: gdb 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. --- With best regards, Konstantin ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Running testsuite on QEMU (sorry if possible duplicate) 2022-09-22 10:31 Running testsuite on QEMU (sorry if possible duplicate) Konstantin Vladimirov @ 2022-09-23 14:51 ` Simon Marchi 2022-09-23 15:26 ` Konstantin Vladimirov 0 siblings, 1 reply; 3+ messages in thread From: Simon Marchi @ 2022-09-23 14:51 UTC (permalink / raw) To: Konstantin Vladimirov, gdb 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Running testsuite on QEMU (sorry if possible duplicate) 2022-09-23 14:51 ` Simon Marchi @ 2022-09-23 15:26 ` Konstantin Vladimirov 0 siblings, 0 replies; 3+ messages in thread From: Konstantin Vladimirov @ 2022-09-23 15:26 UTC (permalink / raw) To: Simon Marchi; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-09-23 15:27 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-09-22 10:31 Running testsuite on QEMU (sorry if possible duplicate) Konstantin Vladimirov 2022-09-23 14:51 ` Simon Marchi 2022-09-23 15:26 ` Konstantin Vladimirov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).