Re: [PATCH] qemu: make version available in coredump
On 2/15/23 23:05, Stefan Hajnoczi wrote:
> On Tue, 7 Jun 2022 at 16:33, Vladimir Sementsov-Ogievskiy
> 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
>> ---
>>
>> 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?
>
> I CCed Laszlo because I think he worked on crash dumping in the past
> and might know the answer to my question about coredumps.
Apologies -- I don't know. (But, I see the original problem has been
resolved down-thread!)
[FWIW, I've now grepped the tree for QEMU_FULL_VERSION cursorily, and
I'd say doing something like Vladimir's patch, and then replacing all
the references too, could be a good cleanup. At least personally I'm not
a huge fan of macros that expand to string literals (format strings such
as PRIu32, HWADDR_FMT_plx, DMA_ADDR_FMT etc are exceptions of course).
But this is really just a thought in passing.]
Laszlo
>
> Stefan
>
>>
>> softmmu/vl.c | 13 +
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/softmmu/vl.c b/softmmu/vl.c
>> index 4c1e94b00e..1f51a713a0 100644
>> --- a/softmmu/vl.c
>> +++ b/softmmu/vl.c
>> @@ -164,6 +164,19 @@ typedef struct DeviceOption {
>> QTAILQ_ENTRY(DeviceOption) next;
>> } DeviceOption;
>>
>> +/*
>> + * qemu_full_version_decl is for debugging. Assume you have coredump file,
>> but
>> + * don't know the version neither have original qemu binary file. You need
>> to
>> + * download a package with corresponding binary (and debug package with
>> + * symbols), but which one? You need the version.
>> + *
>> + * This variable makes it simple to get the version by command
>> + *
>> + * strings path/to/core | grep QEMU_FULL_VERSION
>> + */
>> +static volatile const char qemu_full_version_decl[] =
>> +"QEMU_FULL_VERSION: " QEMU_FULL_VERSION;
>> +
>> static const char *cpu_option;
>> static const char *mem_path;
>> static const char *incoming;
>> --
>> 2.25.1
>>
>>
>
Re: [PATCH] qemu: make version available in coredump
On 16.02.23 15:03, Daniel P. Berrangé wrote:
On Thu, Feb 16, 2023 at 02:30:16PM +0300, Vladimir Sementsov-Ogievskiy wrote:
On 16.02.23 12:44, Daniel P. Berrangé wrote:
On Wed, Feb 15, 2023 at 05:05:47PM -0500, Stefan Hajnoczi wrote:
On Tue, 7 Jun 2022 at 16:33, Vladimir Sementsov-Ogievskiy
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
---
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"}
Looks very good
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.
Generic solution is of course better.
Hmm. I'm on Ubuntu 22.04.
readelf -n /usr/bin/qemu-system-x86_64
Displaying notes found in: .note.gnu.property
OwnerData sizeDescription
GNU 0x0020 NT_GNU_PROPERTY_TYPE_0
Properties: x86 feature: IBT, SHSTK
x86 ISA needed: x86-64-baseline
Displaying notes found in: .note.gnu.build-id
OwnerData sizeDescription
GNU 0x0014 NT_GNU_BUILD_ID (unique build ID
bitstring)
Build ID: 4298cd7c2623c58e1cd71668d9d48508bb7f8d52
Displaying notes found in: .note.ABI-tag
OwnerData sizeDescription
GNU 0x0010 NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 3.2.0
OK. But I can't find this build-id in core file..
readelf -n /tmp/cores/core.qemu-system-x86.20351.vsementsov-win.1676544081 |
grep -i 'build' gets nothing
strings /tmp/cores//core.qemu-system-x86.20351.vsementsov-win.1676544081 | grep
4298cd7c2623c58e nothing as well
I don't understand why that's not visible directly, I guess it must
be encoded in some binary format instead, because at least tools like
eu-unstrip can extract it. eg "
# eu-unstrip -n --core a
O, great! That works for me on Ubuntu.
0x558ff8145000+0xd3f000 e3143405b7f653a0a65b3295df760fdf2c09ba79@0x558ff81453d0
. - /usr/bin/qemu-system-x86_64
0x7fffdf36e000+0x1000 9ff92e165010e0806172add635849ec55533b287@0x7fffdf36e554 .
- linux-vdso.so.1
0x7f00d2e35000+0x6028 e62598a2d2be298ca20184413edea75fc5a3f1d7@0x7f00d2e352f8
/usr/bin/../lib64/qemu/accel-tcg-x86_64.so - accel-tcg-x86_64.so
0x7f00d02bd000+0x432b0 05ba68b0c1f03dd879a78a4a8b75713d7134bdbc@0x7f00d02bd2f8
/usr/lib64/gvfs/libgvfscommon.so - libgvfscommon.so
0x7f00d0301000+0x34300 7c9fd184be4d2c3593d4901feca9fd59c4981d11@0x7f00d03012f8
/usr/lib64/gio/modules/libgvfsdbus.so - libgvfsdbus.so
0x7f00d2e3c000+0xf0e0 08e41432bd5cec0b0dd36158402ce963c711e46f@0x7f00d2e3c2f8
/usr/lib64/gio/modules/libdconfsettings.so - libdconfsettings.so
0x7f00d0491000+0x22008 ee65b3f0999329d66676c60df8ed1feaab83e15f@0x7f00d04912f8
/lib64/libbrotlicommon.so.1 - libbrotlicommon.so.1
0x7f00d094b000+0x8008
Re: [PATCH] qemu: make version available in coredump
On Thu, Feb 16, 2023 at 02:30:16PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> On 16.02.23 12:44, Daniel P. Berrangé wrote:
> > On Wed, Feb 15, 2023 at 05:05:47PM -0500, Stefan Hajnoczi wrote:
> > > On Tue, 7 Jun 2022 at 16:33, Vladimir Sementsov-Ogievskiy
> > > 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
> > > > ---
> > > >
> > > > 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"}
>
> Looks very good
>
> >
> > 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.
>
>
> Generic solution is of course better.
>
> Hmm. I'm on Ubuntu 22.04.
>
> readelf -n /usr/bin/qemu-system-x86_64
>
> Displaying notes found in: .note.gnu.property
> OwnerData sizeDescription
> GNU 0x0020 NT_GNU_PROPERTY_TYPE_0
> Properties: x86 feature: IBT, SHSTK
> x86 ISA needed: x86-64-baseline
>
> Displaying notes found in: .note.gnu.build-id
> OwnerData sizeDescription
> GNU 0x0014 NT_GNU_BUILD_ID (unique build ID
> bitstring)
> Build ID: 4298cd7c2623c58e1cd71668d9d48508bb7f8d52
>
> Displaying notes found in: .note.ABI-tag
> OwnerData sizeDescription
> GNU 0x0010 NT_GNU_ABI_TAG (ABI version tag)
> OS: Linux, ABI: 3.2.0
>
>
> OK. But I can't find this build-id in core file..
>
> readelf -n /tmp/cores/core.qemu-system-x86.20351.vsementsov-win.1676544081 |
> grep -i 'build' gets nothing
>
> strings /tmp/cores//core.qemu-system-x86.20351.vsementsov-win.1676544081 |
> grep 4298cd7c2623c58e nothing as well
I don't understand why that's not visible directly, I guess it must
be encoded in some binary format instead, because at least tools like
eu-unstrip can extract it. eg "
# eu-unstrip -n --core a
0x558ff8145000+0xd3f000 e3143405b7f653a0a65b3295df760fdf2c09ba79@0x558ff81453d0
. - /usr/bin/qemu-system-x86_64
0x7fffdf36e000+0x1000 9ff92e165010e0806172add635849ec55533b287@0x7fffdf36e554 .
- linux-vdso.so.1
0x7f00d2e35000+0x6028 e62598a2d2be298ca20184413edea75fc5a3f1d7@0x7f00d2e352f8
/usr/bin/../lib64/qemu/accel-tcg-x86_64.so - accel-tcg-x86_64.so
0x7f00d02bd000+0x432b0 05ba68b0c1f03dd879a78a4a8b75713d7134bdbc@0x7f00d02bd2f8
/usr/lib64/gvfs/libgvfscommon.so - libgvfscommon.so
0x7f00d0301000+0x34300 7c9fd184be4d2c3593d4901feca9fd59c4981d11@0x7f00d03012f8
/usr/lib64/gio/modules/libgvfsdbus.so - libgvfsdbus.so
0x7f00d2e3c000+0xf0e0
Re: [PATCH] qemu: make version available in coredump
On 16.02.23 12:44, Daniel P. Berrangé wrote:
On Wed, Feb 15, 2023 at 05:05:47PM -0500, Stefan Hajnoczi wrote:
On Tue, 7 Jun 2022 at 16:33, Vladimir Sementsov-Ogievskiy
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
---
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"}
Looks very good
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.
Generic solution is of course better.
Hmm. I'm on Ubuntu 22.04.
readelf -n /usr/bin/qemu-system-x86_64
Displaying notes found in: .note.gnu.property
OwnerData sizeDescription
GNU 0x0020 NT_GNU_PROPERTY_TYPE_0
Properties: x86 feature: IBT, SHSTK
x86 ISA needed: x86-64-baseline
Displaying notes found in: .note.gnu.build-id
OwnerData sizeDescription
GNU 0x0014 NT_GNU_BUILD_ID (unique build ID
bitstring)
Build ID: 4298cd7c2623c58e1cd71668d9d48508bb7f8d52
Displaying notes found in: .note.ABI-tag
OwnerData sizeDescription
GNU 0x0010 NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 3.2.0
OK. But I can't find this build-id in core file..
readelf -n /tmp/cores/core.qemu-system-x86.20351.vsementsov-win.1676544081 |
grep -i 'build' gets nothing
strings /tmp/cores//core.qemu-system-x86.20351.vsementsov-win.1676544081 | grep
4298cd7c2623c58e nothing as well
So the case is to find the package not having the binary, only by core file.
Probably right solution is to fix our workflow so that if you have core file
you always have corresponding binary as well.
Still, having the information exactly inside core file seems good anyway. Maybe there is
a generic way to force the system put "Packaging Metadata" into core file on
creation of it?
--
Best regards,
Vladimir
Re: [PATCH] qemu: make version available in coredump
On Wed, Feb 15, 2023 at 05:05:47PM -0500, Stefan Hajnoczi wrote:
> On Tue, 7 Jun 2022 at 16:33, Vladimir Sementsov-Ogievskiy
> 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
> > ---
> >
> > 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 :|
Re: [PATCH] qemu: make version available in coredump
On Tue, 7 Jun 2022 at 16:33, Vladimir Sementsov-Ogievskiy
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
> ---
>
> 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?
I CCed Laszlo because I think he worked on crash dumping in the past
and might know the answer to my question about coredumps.
Stefan
>
> softmmu/vl.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/softmmu/vl.c b/softmmu/vl.c
> index 4c1e94b00e..1f51a713a0 100644
> --- a/softmmu/vl.c
> +++ b/softmmu/vl.c
> @@ -164,6 +164,19 @@ typedef struct DeviceOption {
> QTAILQ_ENTRY(DeviceOption) next;
> } DeviceOption;
>
> +/*
> + * qemu_full_version_decl is for debugging. Assume you have coredump file,
> but
> + * don't know the version neither have original qemu binary file. You need to
> + * download a package with corresponding binary (and debug package with
> + * symbols), but which one? You need the version.
> + *
> + * This variable makes it simple to get the version by command
> + *
> + * strings path/to/core | grep QEMU_FULL_VERSION
> + */
> +static volatile const char qemu_full_version_decl[] =
> +"QEMU_FULL_VERSION: " QEMU_FULL_VERSION;
> +
> static const char *cpu_option;
> static const char *mem_path;
> static const char *incoming;
> --
> 2.25.1
>
>
Re: [PATCH] qemu: make version available in coredump
ping) -- Best regards, Vladimir
