Port-sparc64 archive

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

Re: virtio hard disk on qemu



On Fri, Jan 27, 2023 at 09:26:15AM +0000, Mark Cave-Ayland wrote:
> For recent versions of QEMU the easiest way to get a debug build is to pass
> --enable-debug to configure (when setting CFLAGS there are some subtleties
> around how CFLAGS is passed into the various external git submodules).

Thanks, that was helpful.

> For a debug backtrace you'll want to include all the threads so "thread
> apply all bt full" would be useful.
> 
> Finally you'll want the meson output generated by configure since there are
> all sorts of interesting bits and pieces there.

$ file /usr/pkgsrc/emulators/qemu/work/qemu-7.2.0/build/qemu-system-sparc64
/usr/pkgsrc/emulators/qemu/work/qemu-7.2.0/build/qemu-system-sparc64: ELF 64-bit MSB pie executable, SPARC V9, relaxed memory ordering, version 1 (SYSV), dynamically linked, interpreter /usr/libexec/ld.elf_so, for NetBSD 9.3, compiler model: medmid, with debug_info, not stripped
$ gdb -q /usr/pkgsrc/emulators/qemu/work/qemu-7.2.0/build/qemu-system-sparc64
Reading symbols from /usr/pkgsrc/emulators/qemu/work/qemu-7.2.0/build/qemu-system-sparc64...
(gdb) info files
Symbols from "/usr/pkgsrc/emulators/qemu/work/qemu-7.2.0/build/qemu-system-sparc64".
Local exec file:
        `/usr/pkgsrc/emulators/qemu/work/qemu-7.2.0/build/qemu-system-sparc64', file type elf64-sparc.
        Entry point: 0x2f5bc0
[...]
(gdb) break * 0x2f5bc0
Breakpoint 1 at 0x2f5bc0
(gdb) run
Starting program: /usr/pkgsrc/emulators/qemu/work/qemu-7.2.0/build/qemu-system-sparc64
[ 351.7455919] load: 0.24  cmd: qemu-system-spar 1214 [parked] 0.66u 0.14s 0% 11344k

Program received signal SIGINFO, Information request.
0x0000000044109ba8 in ?? () from /usr/lib/libpthread.so.1
(gdb) thread apply all bt full

Thread 1 (LWP 1214 of process 1214):
#0  0x0000000044109ba8 in ?? () from /usr/lib/libpthread.so.1
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

That kernel message is me typing ^T (SIGINFO), after waiting
perhaps 10-20 seconds -- just a convenient way of getting a gdb
prompt.

I guess what I don't understand is why the breakpoint I set at the
entry point for the program isn't hit. I've tried breaking at main,
qemu_init, etc, but it doesn't seem to matter which breakpoint I
set, nothing is ever triggered, and the program launch just seems
to stall.

Many thanks,
Tyler


Home | Main Index | Thread Index | Old Index