Re: [PATCH] qemu: make version available in coredump

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

On Wed, Feb 15, 2023 at 05:05:47PM -0500, Stefan Hajnoczi wrote:
> On Tue, 7 Jun 2022 at 16:33, Vladimir Sementsov-Ogievskiy
> <vsementsov@yandex-team.ru> wrote:
> >
> > Add a variable with QEMU_FULL_VERSION definition. Then the content of
> > the variable is easily searchable:
> >
> >    strings /path/to/core | grep QEMU_FULL_VERSION
> >
> > 'volatile' keyword is used to avoid removing the variable by compiler as
> > unused.
> >
> > Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
> > ---
> >
> > Hi all!
> >
> > Probably, I just don't know the correct way to get version from core
> > file. If so, please teach me :)
> 
> I've never hit this issue because bug reports usually include the QEMU
> distro package version. Keeping the version string in the core file
> seems reasonable (unless there is already another way to do this).
> 
> Something I'm curious about: is the coredump guaranteed to contain
> static const variables? I wondered if they might be located in the
> .rodata ELF section and excluded from the coredump because they are
> referenced in the NT_FILE mmap note instead. Maybe volatile prevents
> this?

In Fedora / RHEL based systems (and some other distros too IIUC) for
many years, all binaries have included a "build-id" ELF note which
uniquely identifies the package build.

Note section [ 3] '.note.gnu.build-id' of 36 bytes at offset 0x3c0:
  Owner          Data size  Type
  GNU                   20  GNU_BUILD_ID
    Build ID: e3143405b7f653a0a65b3295df760fdf2c09ba79

This can be used to query what RPM it came from (assuming the RPM
is still in your repos)

 dnf repoquery --whatprovides debuginfo(build-id) = ...hash...

this makes it into the coredump files and is what current distro
tooling uses to find the binary (and libraries).

There are some downsides/limitations with this though, so in
Fedora 36 a new impl was added alongside which provides full
package info in json

Note section [ 5] '.note.package' of 136 bytes at offset 0x404:
  Owner          Data size  Type
  FDO                  120  FDO_PACKAGING_METADATA
    Packaging Metadata: {"type":"rpm","name":"qemu","version":"7.0.0-13.fc37","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:37"}

This format is supported by systemd core dump tools

  https://systemd.io/ELF_PACKAGE_METADATA/

I believe it has been proposed (and possibly implemented?) for
Debian too.

This is a long winded way of asking, do we really need a QEMU specific
solution here ? Especially one that only tells us a QEMU verison, and
nothing about the many libraries QEMU links to which affect its
operational behaviour.

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