All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Weil <weil@mail.berlios.de>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Blue Swirl <blauwirbel@gmail.com>, TeLeMan <geleman@gmail.com>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: [Qemu-devel] Re: [PATCH 4/4] target-xxx: Use fprintf_function (format checking)
Date: Mon, 01 Nov 2010 16:18:58 +0100	[thread overview]
Message-ID: <4CCEDA62.4060006@mail.berlios.de> (raw)
In-Reply-To: <4CCE9E94.2030906@redhat.com>

Am 01.11.2010 12:03, schrieb Paolo Bonzini:
> 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

Yes. We already had a similar discussion about TARGET_FMT_PLX, see
http://www.mail-archive.com/qemu-devel@nongnu.org/msg42977.html.

There I suggested to define PRIxTPA (format specifier for a target
physical address). We could also add a PRIxTUL (for target_ulong),
so it would be possible to output "%04" PRIxTUL or "%08" PRIxTUL.
Thus we could avoid the need for TARGET_FMT_8lx, TARGET_FMT_4lx
and maybe even TARGET_FMT_2lx.

Kind regards,
Stefan

  reply	other threads:[~2010-11-01 15:19 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
2010-11-01 15:18               ` Stefan Weil [this message]
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=4CCEDA62.4060006@mail.berlios.de \
    --to=weil@mail.berlios.de \
    --cc=blauwirbel@gmail.com \
    --cc=geleman@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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.