[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-discuss] Debugging qemu inside chroot
From: |
Paulo Matos |
Subject: |
[Qemu-discuss] Debugging qemu inside chroot |
Date: |
Wed, 20 Mar 2019 23:05:36 +0100 |
Hi,
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.
I thought, well, instead of
chroot aarch64-chroot gdb --args /racket/racket/bin/racket3m ...
I can do:
chroot aarch64-chroot gdb --args /usr/bin/qemu-aarch64-static
/racket/racket/bin/racket3m ...
except I can't because the chroot gdb is compiled for aarch64 and
qemu-aarch64-static is an x86_64 binary.
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 ...
But this doesn't work either because it complains of a missing
/lib/ld-aarch64.so or something of the sort. This is probably happening
when qemu loads the binary and this fails because the racket binary
attempts to load its dynamic linked libraries and fails because the
libraries do not exist outside the chroot.
How are these problems usually debugged?
Kind regards,
--
Paulo Matos
- [Qemu-discuss] Debugging qemu inside chroot,
Paulo Matos <=