From: Paolo Bonzini <pbonzini@redhat.com>
To: TeLeMan <geleman@gmail.com>, Blue Swirl <blauwirbel@gmail.com>,
qemu-devel <qemu-devel@nongnu.org>,
Stefan Weil <weil@mail.berlios.de>
Subject: [Qemu-devel] Re: [PATCH 4/4] target-xxx: Use fprintf_function (format checking)
Date: Mon, 01 Nov 2010 12:03:48 +0100 [thread overview]
Message-ID: <4CCE9E94.2030906@redhat.com> (raw)
In-Reply-To: <AANLkTino2N6qxYxwXu1cLn=oVanETcqOjthfX7qr4_Dh@mail.gmail.com>
On 11/01/2010 11:27 AM, TeLeMan wrote:
> On Mon, Nov 1, 2010 at 18:14, Paolo Bonzini<pbonzini@redhat.com> wrote:
>> On 11/01/2010 10:50 AM, TeLeMan wrote:
>>>>>
>>>>> I think this patch is not right. Outputting 64bits data is not
>>>>> necessary on 32bits mode.
>>>>
>>>> Do you speak of 32 bit hosts or 32 bit targets?
>>>
>>> 32bit mode of x64
>>
>> There is no such thing as a 32 bit host on x64, only 64-bit hosts that
>> haven't turned on long mode. So printing 64 bits is correct for those.
>
> If so, why the above crX is printed by 32 bits?
There are two issues. One is what type specifier to use (and it is a
correctness issue), the other is what width to use (and it is an
aesthetics issue). The patch fixes the correctness issue and makes the
aesthetic part worse.
I agree that a better fix would be to cast to uint32_t as it is done for
crX, but this patch is anyway better than nothing because right now DR7
is printed incorrectly _exactly on 64-bit guests running on 32-bit mode_.
An even better fix than uint32_t would be to introduce TARGET_FMT_8lx
(which maps to "%08"PRI_x64) so that, if for some reason the high 32-bit
are not zero, they will be shown.
Paolo
next prev parent reply other threads:[~2010-11-01 11:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-22 21:03 [Qemu-devel] [PATCH 1/4] Add fprintf_function for function pointers to fprintf-like functions Stefan Weil
2010-10-22 21:03 ` [Qemu-devel] [PATCH 2/4] tcg: Use fprintf_function (format checking) Stefan Weil
2010-10-22 21:03 ` [Qemu-devel] [PATCH 3/4] exec: Use fprintf_function for dump_exec_info " Stefan Weil
2010-10-22 21:03 ` [Qemu-devel] [PATCH 4/4] target-xxx: Use fprintf_function " Stefan Weil
2010-11-01 2:24 ` TeLeMan
2010-11-01 7:05 ` Stefan Weil
2010-11-01 9:50 ` TeLeMan
2010-11-01 10:14 ` [Qemu-devel] " Paolo Bonzini
2010-11-01 10:20 ` Paolo Bonzini
[not found] ` <AANLkTino2N6qxYxwXu1cLn=oVanETcqOjthfX7qr4_Dh@mail.gmail.com>
2010-11-01 11:03 ` Paolo Bonzini [this message]
2010-11-01 15:18 ` Stefan Weil
2010-11-01 15:42 ` Paolo Bonzini
2010-10-30 9:23 ` [Qemu-devel] Re: [PATCH 1/4] Add fprintf_function for function pointers to fprintf-like functions Blue Swirl
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=4CCE9E94.2030906@redhat.com \
--to=pbonzini@redhat.com \
--cc=blauwirbel@gmail.com \
--cc=geleman@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=weil@mail.berlios.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.