qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Use of TARGET_FMT_plx in hw/tpm/trace-events


From: Philippe Mathieu-Daudé
Subject: Re: [Qemu-devel] Use of TARGET_FMT_plx in hw/tpm/trace-events
Date: Sat, 20 Jul 2019 11:42:07 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

On 7/20/19 8:39 AM, Markus Armbruster wrote:
> Consider hw/tpm/trace-events
> 
>     # tpm_crb.c
>     tpm_crb_mmio_read(uint64_t addr, unsigned size, uint32_t val) "CRB read 
> 0x" TARGET_FMT_plx " len:%u val: 0x%" PRIx32
>     tpm_crb_mmio_write(uint64_t addr, unsigned size, uint32_t val) "CRB write 
> 0x" TARGET_FMT_plx " len:%u val: 0x%" PRIx32
> 
> Format is TARGET_FMT_plx formats a hwaddr, but the parameter type is
> uint64_t.  They happen to be the same.  Is this kosher?
> 

Missed when converting from DPRINTF() to trace-events:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=ec427498;hp=8cb340c613

PRIx64 certainly makes sense here.

Since it is the single use, once updated we can remote this hunk from
scripts/tracetool/format/log_stap.py:

    if macro == "TARGET_FMT_plx":
        return "%016x"

I guess remember a thread with Thomas talking about TARGET_FMT_plx but I
can't find it, maybe I dreamed about it...

The idea was, we poison TARGET_FMT_l[udx] but not TARGET_FMT_plx, we
could, but then we have to fix few formats, once done TARGET_FMT_plx
existence is almost irrelevant.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]