From: Laszlo Ersek <lersek@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>,
Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Cc: qemu-devel@nongnu.org, pbonzini@redhat.com
Subject: Re: [PATCH] qemu: make version available in coredump
Date: Mon, 20 Feb 2023 09:29:25 +0100 [thread overview]
Message-ID: <3468a643-6bea-9243-3569-23a07cca582d@redhat.com> (raw)
In-Reply-To: <CAJSP0QVNnGg+5OkDwpk3Kgc=kicsSt+f5QVg1tyd+ze76N_KVw@mail.gmail.com>
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
>>
>>
>
prev parent reply other threads:[~2023-02-20 8:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-07 20:32 [PATCH] qemu: make version available in coredump Vladimir Sementsov-Ogievskiy
2023-02-15 21:19 ` Vladimir Sementsov-Ogievskiy
2023-02-15 22:05 ` Stefan Hajnoczi
2023-02-16 9:44 ` Daniel P. Berrangé
2023-02-16 11:30 ` Vladimir Sementsov-Ogievskiy
2023-02-16 12:03 ` Daniel P. Berrangé
2023-02-16 17:02 ` Vladimir Sementsov-Ogievskiy
2023-02-20 8:29 ` Laszlo Ersek [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3468a643-6bea-9243-3569-23a07cca582d@redhat.com \
--to=lersek@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=vsementsov@yandex-team.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).