Re: [PATCH 4/4] scripts/qemugdb: coroutine: Add option for obtaining detailed trace in coredump

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Nov 27, 2025 at 10:56:12AM +0100, Kevin Wolf wrote:
> Am 25.11.2025 um 15:21 hat andrey.drobyshev@virtuozzo.com geschrieben:
> > From: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
> > 
> > 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.
> > [...]
> 
> > +def clone_coredump(source, target, set_regs):
> > +    shutil.copyfile(source, target)
> > +    write_regs_to_coredump(target, set_regs)
> > +
> > +def dump_backtrace_patched(regs):
> > +    files = gdb.execute('info files', False, True).split('\n')
> > +    executable = re.match('^Symbols from "(.*)".$', files[0]).group(1)
> > +    dump = re.search("`(.*)'", files[2]).group(1)
> > +
> > +    with tempfile.NamedTemporaryFile(dir='/tmp', delete=False) as f:
> > +        tmpcore = f.name
> > +
> > +    clone_coredump(dump, tmpcore, regs)
> 
> I think this is what makes it so heavy, right? Coredumps can be quite
> large and /tmp is probably a different filesystem, so you end up really
> copying the full size of the coredump around.

On my system /tmp is  tmpfs, so this is actually bringing the whole
coredump into RAM which is not a sensible approach.

> Wouldn't it be better in the general case if we could just do a reflink
> copy of the coredump and then do only very few writes for updating the
> register values? Then the overhead should actually be quite negligible
> both in terms of time and disk space.

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. 


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 :|