| Message ID | 20220607203221.966261-1-vsementsov@yandex-team.ru |
|---|---|
| State | New |
| Headers | show |
| Series | qemu: make version available in coredump | expand |
ping)
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? 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 > >
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
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 >> <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"} 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 Owner Data size Description GNU 0x00000020 NT_GNU_PROPERTY_TYPE_0 Properties: x86 feature: IBT, SHSTK x86 ISA needed: x86-64-baseline Displaying notes found in: .note.gnu.build-id Owner Data size Description GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring) Build ID: 4298cd7c2623c58e1cd71668d9d48508bb7f8d52 Displaying notes found in: .note.ABI-tag Owner Data size Description GNU 0x00000010 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?
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 > > > <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"} > > 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 > Owner Data size Description > GNU 0x00000020 NT_GNU_PROPERTY_TYPE_0 > Properties: x86 feature: IBT, SHSTK > x86 ISA needed: x86-64-baseline > > Displaying notes found in: .note.gnu.build-id > Owner Data size Description > GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring) > Build ID: 4298cd7c2623c58e1cd71668d9d48508bb7f8d52 > > Displaying notes found in: .note.ABI-tag > Owner Data size Description > GNU 0x00000010 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 08e41432bd5cec0b0dd36158402ce963c711e46f@0x7f00d2e3c2f8 /usr/lib64/gio/modules/libdconfsettings.so - libdconfsettings.so 0x7f00d0491000+0x22008 ee65b3f0999329d66676c60df8ed1feaab83e15f@0x7f00d04912f8 /lib64/libbrotlicommon.so.1 - libbrotlicommon.so.1 0x7f00d094b000+0x8008 73a48146553f6009aea4cbfe65a01fed665c9bed@0x7f00d094b2f8 /lib64/libdatrie.so.1 - libdatrie.so.1 0x7f00d0954000+0x22008 5c9099941d5c7af74f952367da1368a78d06347c@0x7f00d09542f8 /lib64/liblz4.so.1 - liblz4.so.1 0x7f00d0977000+0x9038 f3f24bb6e411e3885602e753eda1e764fc1f5bfb@0x7f00d09772f8 /lib64/libcap.so.2 - libcap.so.2 0x7f00ca200000+0x1d05008 47276216e74b87c4b9bd01ac85c7bf332e6f2aed@0x7f00ca2002c0 /lib64/libicudata.so.71 - libicudata.so.71 0x7f00d0981000+0x5020 5f69b36d838d0ec4967f94dd1ea95fd830262997@0x7f00d09812f8 /lib64/libXau.so.6 - libXau.so.6 0x7f00d0987000+0xc008 5fc05a35af263c2149bb2c0fae2533c2ebe0a225@0x7f00d09872f8 /lib64/libbrotlidec.so.1 - libbrotlidec.so.1 0x7f00d0994000+0x12c08 101a76ab214af7a108f9a601fd298bcf405eff5d@0x7f00d09942f8 /lib64/libbz2.so.1 - libbz2.so.1 0x7f00d04b4000+0x14beb8 931d94ba5734f5d1a4b24af1283af44c786ef5d0@0x7f00d04b42f8 /lib64/libsqlite3.so.0 - libsqlite3.so.0 0x7f00d09a7000+0x2b198 e21ae41532eae88d92bd3b18dd7cba5d3873f960@0x7f00d09a72f8 /lib64/libjson-glib-1.0.so.0 - libjson-glib-1.0.so.0 0x7f00d0600000+0x32e328 f4748e4011f7e0fd328ade31e62bc9167e417b74@0x7f00d06002f8 /lib64/libicui18n.so.71 - libicui18n.so.71 0x7f00d09d3000+0x540a8 a3251522721d67203dd4dbe5166334f6643d16c0@0x7f00d09d32f8 /lib64/libstemmer.so.0 - libstemmer.so.0 0x7f00d0a28000+0x3c4a8 62c94aa0bc23c6d131160f48caaef6afdc7625ca@0x7f00d0a282f8 /lib64/libatspi.so.0 - libatspi.so.0 0x7f00d0a65000+0x542c8 d0687c050fb1599e99195661d70fdbbe6bf9c4b1@0x7f00d0a652f8 /lib64/libdbus-1.so.3 - libdbus-1.so.3 0x7f00d0aba000+0x179728 946e0bba5825d11471d055a39041747e2db65d7a@0x7f00d0aba2f8 /lib64/libxml2.so.2 - libxml2.so.2 0x7f00d0c34000+0x21008 24975d617308ccea1539745afa0ace7a6057f225@0x7f00d0c342f8 /lib64/libgraphite2.so.3 - libgraphite2.so.3 0x7f00d0c56000+0xa870 99e9f4339b7296c8be1d4e1a51049598ffc9af1e@0x7f00d0c562f8 /lib64/libthai.so.0 - libthai.so.0 0x7f00d0c61000+0xdc578 35de99f90f9858bb028b57fa6eef9d8238562527@0x7f00d0c61330 /lib64/libsystemd.so.0 - libsystemd.so.0 0x7f00d0d3e000+0x1fc2a0 f0a97a601f057dd0739c60482ff1b33c5e054456@0x7f00d0d3e2f8 /lib64/libicuuc.so.71 - libicuuc.so.71 > 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. With debuginfod present, Fedora can find the binaries, even if they are not installed. Older RHEL versions probably lack this, but IIRC it should bein RHEL-9 With regards, Daniel
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 >>>> <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"} >> >> 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 >> Owner Data size Description >> GNU 0x00000020 NT_GNU_PROPERTY_TYPE_0 >> Properties: x86 feature: IBT, SHSTK >> x86 ISA needed: x86-64-baseline >> >> Displaying notes found in: .note.gnu.build-id >> Owner Data size Description >> GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring) >> Build ID: 4298cd7c2623c58e1cd71668d9d48508bb7f8d52 >> >> Displaying notes found in: .note.ABI-tag >> Owner Data size Description >> GNU 0x00000010 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 73a48146553f6009aea4cbfe65a01fed665c9bed@0x7f00d094b2f8 /lib64/libdatrie.so.1 - libdatrie.so.1 > 0x7f00d0954000+0x22008 5c9099941d5c7af74f952367da1368a78d06347c@0x7f00d09542f8 /lib64/liblz4.so.1 - liblz4.so.1 > 0x7f00d0977000+0x9038 f3f24bb6e411e3885602e753eda1e764fc1f5bfb@0x7f00d09772f8 /lib64/libcap.so.2 - libcap.so.2 > 0x7f00ca200000+0x1d05008 47276216e74b87c4b9bd01ac85c7bf332e6f2aed@0x7f00ca2002c0 /lib64/libicudata.so.71 - libicudata.so.71 > 0x7f00d0981000+0x5020 5f69b36d838d0ec4967f94dd1ea95fd830262997@0x7f00d09812f8 /lib64/libXau.so.6 - libXau.so.6 > 0x7f00d0987000+0xc008 5fc05a35af263c2149bb2c0fae2533c2ebe0a225@0x7f00d09872f8 /lib64/libbrotlidec.so.1 - libbrotlidec.so.1 > 0x7f00d0994000+0x12c08 101a76ab214af7a108f9a601fd298bcf405eff5d@0x7f00d09942f8 /lib64/libbz2.so.1 - libbz2.so.1 > 0x7f00d04b4000+0x14beb8 931d94ba5734f5d1a4b24af1283af44c786ef5d0@0x7f00d04b42f8 /lib64/libsqlite3.so.0 - libsqlite3.so.0 > 0x7f00d09a7000+0x2b198 e21ae41532eae88d92bd3b18dd7cba5d3873f960@0x7f00d09a72f8 /lib64/libjson-glib-1.0.so.0 - libjson-glib-1.0.so.0 > 0x7f00d0600000+0x32e328 f4748e4011f7e0fd328ade31e62bc9167e417b74@0x7f00d06002f8 /lib64/libicui18n.so.71 - libicui18n.so.71 > 0x7f00d09d3000+0x540a8 a3251522721d67203dd4dbe5166334f6643d16c0@0x7f00d09d32f8 /lib64/libstemmer.so.0 - libstemmer.so.0 > 0x7f00d0a28000+0x3c4a8 62c94aa0bc23c6d131160f48caaef6afdc7625ca@0x7f00d0a282f8 /lib64/libatspi.so.0 - libatspi.so.0 > 0x7f00d0a65000+0x542c8 d0687c050fb1599e99195661d70fdbbe6bf9c4b1@0x7f00d0a652f8 /lib64/libdbus-1.so.3 - libdbus-1.so.3 > 0x7f00d0aba000+0x179728 946e0bba5825d11471d055a39041747e2db65d7a@0x7f00d0aba2f8 /lib64/libxml2.so.2 - libxml2.so.2 > 0x7f00d0c34000+0x21008 24975d617308ccea1539745afa0ace7a6057f225@0x7f00d0c342f8 /lib64/libgraphite2.so.3 - libgraphite2.so.3 > 0x7f00d0c56000+0xa870 99e9f4339b7296c8be1d4e1a51049598ffc9af1e@0x7f00d0c562f8 /lib64/libthai.so.0 - libthai.so.0 > 0x7f00d0c61000+0xdc578 35de99f90f9858bb028b57fa6eef9d8238562527@0x7f00d0c61330 /lib64/libsystemd.so.0 - libsystemd.so.0 > 0x7f00d0d3e000+0x1fc2a0 f0a97a601f057dd0739c60482ff1b33c5e054456@0x7f00d0d3e2f8 /lib64/libicuuc.so.71 - libicuuc.so.71 > >> 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. > > With debuginfod present, Fedora can find the binaries, even if they > are not installed. Older RHEL versions probably lack this, but IIRC > it should bein RHEL-9 > Ok, I see now how finding the binary may be automated without the patch, so it's not really needed. Thanks!
On 2/15/23 23:05, 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? > > 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 >> >> >
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;
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 :) softmmu/vl.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)