On 12 January 2012 23:47, Andreas Färber wrote:
> PRI* should never include % or width specifier or prefix.
>
> What we should IMO do is:
>
> #define PRIdPLX PRId64
> #define PRIxPLX PRIx64
> #define PRIXPLX PRIX64
> /* or TARGET_PRI*PHYS or whatever */
>
> This can then be used as "... %02" PRIxP
Am 12.01.2012 23:56, schrieb Anthony Liguori:
> On 01/12/2012 04:46 PM, Peter Maydell wrote:
> I think a reasonable thing to do is:
>
> #define PRIp64 "0x%08" PRIx64
>
> s:TARGET_FMT_plx:PRIp64:g
Nack, that is unreasonable naming and does not solve the issue pointed
out by Peter. PRI* should nev
On 12 January 2012 22:56, Anthony Liguori wrote:
> This code is broken in its current form. target_phys_addr_t has an
> unspecified width which is why we provide a FMT for it.
I don't think it's been clear that target_phys_addr_t has a
width which might not be the width of the target's physical
On 01/12/2012 04:46 PM, Peter Maydell wrote:
On 12 January 2012 22:42, Peter Maydell wrote:
You're the one changing what was previously a known-to-be-32-bit
type to one that's much bigger, you get to fix the printing
issues.
This code is broken in its current form. target_phys_addr_t has an
On 12 January 2012 22:42, Peter Maydell wrote:
> You're the one changing what was previously a known-to-be-32-bit
> type to one that's much bigger, you get to fix the printing
> issues.
...which isn't to say that I don't think this is a good
plan (indeed I suspect I'm going to need wider physaddr
On 12 January 2012 20:32, Anthony Liguori wrote:
> On 01/12/2012 02:06 PM, Peter Maydell wrote:
>>
>> On 12 January 2012 17:54, Anthony Liguori wrote:
>>>
>>> This simplifies the build quite a bit and improves the builds performance
>>> by
>>> not rebuilding many objects twice.
>>>
>>> There were
On 01/12/2012 02:06 PM, Peter Maydell wrote:
On 12 January 2012 17:54, Anthony Liguori wrote:
This simplifies the build quite a bit and improves the builds performance by
not rebuilding many objects twice.
There were a surprising number of places that had assumed wrong things about the
size of
On 12 January 2012 17:54, Anthony Liguori wrote:
> This simplifies the build quite a bit and improves the builds performance by
> not rebuilding many objects twice.
>
> There were a surprising number of places that had assumed wrong things about
> the
> size of target_phys_addr_t including that i
Am 12.01.2012 18:54, schrieb Anthony Liguori:
> This simplifies the build quite a bit and improves the builds performance by
> not rebuilding many objects twice.
>
> There were a surprising number of places that had assumed wrong things about
> the
> size of target_phys_addr_t including that it w
This simplifies the build quite a bit and improves the builds performance by
not rebuilding many objects twice.
There were a surprising number of places that had assumed wrong things about the
size of target_phys_addr_t including that it was fixed at 32-bit and that it
was identical to target_ulon
10 matches
Mail list logo
