On Thu, Nov 27, 2025 at 04:31:29PM +0200, Andrey Drobyshev wrote: > On 11/27/25 12:02 PM, Daniel P. Berrangé wrote: > > On Thu, Nov 27, 2025 at 10:56:12AM +0100, Kevin Wolf wrote: > >> Am 25.11.2025 um 15:21 hat [email protected] geschrieben: > >>> From: Andrey Drobyshev <[email protected]> > >>> > >>> Commit 772f86839f ("scripts/qemu-gdb: Support coroutine dumps in > >>> coredumps") introduced coroutine traces in coredumps using raw stack > >>> unwinding. While this works, this approach does not allow to view the > >>> function arguments in the corresponding stack frames. > >>> > >>> As an alternative, we can obtain saved registers from the coroutine's > >>> jmpbuf, copy the original coredump file into a temporary file, patch the > >>> saved registers into the tmp coredump's struct elf_prstatus and execute > >>> another gdb subprocess to get backtrace from the patched temporary > >>> coredump. > >>> > >>> While providing more detailed info, this alternative approach, however, is > >>> quite heavyweight as it takes significantly more time and disk space. > >>> So, instead of making it a new default, let's keep raw unwind the default > >>> behaviour, but add the '--detailed' option for 'qemu bt' and 'qemu > >>> coroutine' > >>> command which would enforce the new behaviour. > >>> [...] > >>
> > Personally I'd be fine with just modifying the core dump in place > > most of the time. I don't need to keep the current file untouched, > > as it is is just a temporary download acquired from systemd's > > coredumpctl, or from a bug tracker. > > > > > > Hmm, that's an interesting proposal. But I still see some potential > pitfalls with it: > > 1. When dealing with the core dump stored by coredumpctl, original file > is indeed stored compressed and not being modified. We don't really > care about the uncompressed temporary dump placed in /var/tmp. What we > do care about is that current GDB session keeps working smoothly. I > tried patching the dump in place without copying, and it doesn't seem to > break subsequent commands. However GDB keeps the temporary dump open > throughout the whole session, which means it can occasionally read > modified data from it. I'm not sure that we have a solid guarantee that > things will keep working with the patched dump. > > 2. If we're dealing with an external core dump downloaded from a bug > report, we surely want to be able to create new GDB sessions with it. > That means we'll want its unmodified version. Having to re-download it > again is even slower than plain copying. > > The solution to both problems would be saving original registers and > patching them back into the core dump once we've obtained our coroutine > trace. It's still potentially fragile in 2nd case if GDB process > abruptly gets killed/dies leaving registers un-restored. But I guess we > can live with it? > > What do you think? I didn't realize at first that we're actually running this every time a back trace is requested in the session. It feels fragile / risky to be modifying the file repeatedly while QEMU has the orignal file open so probably best to disregard that suggestion of mine. None the less, that makes me even more wary of the full copyfile approach, as we'd be taking that performance hit potentually many times over :-( I don't suppose there's an easy way to make a sparse copy of the file such that we only include the minimum data needed to produce the stack trace and omit other parts (leave all-zeros) ? With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
