[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] Debugging qemu inside chroot

From: Peter Maydell
Subject: Re: [Qemu-discuss] Debugging qemu inside chroot
Date: Thu, 21 Mar 2019 08:15:09 +0000

On Wed, 20 Mar 2019 at 22:19, Paulo Matos <address@hidden> wrote:
> I am trying to debug a segfault that's occurring during the compilation
> phase of the racket language system inside an arm64 debian chroot.
> I get on with the chroot creation well. Then while the racket system
> compiles a crash occurs. This could be qemu or racket. For quite awhile
> I assumed it was racket but I am starting to lean to the side of a
> qemu-aarch64-static problem (compiled from 3.1.0 sources).
> If I run gdb on the racket command line causing the issue inside the gdb
> root I enter gdb and start but the segfault occurs even before I hit
> _start. When the segfault occurs, if I do `bt` it tells me there's no stack.

This won't work, because you'd be trying to emulate an AArch64
gdb inside QEMU, which doesn't work because QEMU doesn't
emulate the ptrace syscall. What you need to do is
run QEMU on your guest binary (racket) and tell QEMU to
enable its builtin gdbstub. Then you can connect to that
via an aarch64-aware built-for-x86 gdb. Something like:

 chroot aarch64-chroot /usr/bin/qemu-aarch64-static -g 1234
/racket../racket3m ...

which should wait for a gdb connection on port 1234 before running.
Then in another host terminal:
and at the gdb prompt
 set arch aarch64
 target remote :1234

("gdb-multiarch" is what Debian and Ubuntu call their gdb
binary that's built to understand multiple target architectures.
Other distros might call it something else. If the 'set arch aarch64'
command gives an error then it's probably because your gdb hasn't
been built with support for multiple target architectures.)

> Then I attempted to run gdb outside of the chroot like:
> gdb --args qemu-3.1.0-install/bin/qemu-aarch64
> aarch64-chroot/racket/racket/bin/racket3m ...

If you want to run x86 gdb on QEMU (to debug/get backtraces
for QEMU itself) you can do something like:

gdb --args chroot aarch64-chroot /usr/bin/qemu-aarch64-static
path/to/racket3m ...

gdb will of course start out by debugging the host chroot binary,
but you can use 'break main' which should cause gdb to ask
"Make breakpoint pending on future shared library load?" -- if you
say yes, then continue, it will break when chroot execs QEMU
and we enter QEMU's main program. (Won't work if you have debug
symbols for chroot for some reason -- if so then use a bp on
some function that's only in QEMU and not in chroot.)

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]