[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 07/10] tb hash: hash phys_pc, pc, and flags with

From: Laurent Desnogues
Subject: Re: [Qemu-devel] [PATCH 07/10] tb hash: hash phys_pc, pc, and flags with xxhash
Date: Thu, 7 Apr 2016 10:12:02 +0200

On Wed, Apr 6, 2016 at 7:42 PM, Richard Henderson <address@hidden> wrote:
> On 04/06/2016 10:32 AM, Emilio G. Cota wrote:
>> On Wed, Apr 06, 2016 at 08:06:57 +0200, Laurent Desnogues wrote:
>>> On Tue, Apr 5, 2016 at 7:19 PM, Richard Henderson <address@hidden> wrote:
>>>> On 04/05/2016 09:33 AM, Laurent Desnogues wrote:
>>>>> The 'flags' field is 64-bit.  You're thinking of cflags, I guess.
>>>> Well that's silly.  Since it's filled in via
>>>> static inline void cpu_get_tb_cpu_state(CPUMIPSState *env, target_ulong 
>>>> *pc,
>>>>                                         target_ulong *cs_base, int *flags)
>>>> and passed back in to generate code with
>>>> TranslationBlock *tb_gen_code(CPUState *cpu,
>>>>                               target_ulong pc, target_ulong cs_base, int 
>>>> flags,
>>>>                               int cflags);
>>>> So while TranslationBlock stores "uint64_t", the producer and consumer see 
>>>> "int".
>>> I agree.  I guess TranslationBlock should be fixed to use uint32_t
>>> (note several functions have to be changed from using int to uint32_t
>>> or aarch64-softmmu will fail).
>> Can you please elaborate on this?
> The arm port is using some high bits, including

Yes, that's why I advocate the use of uint32_t over int.

Emilio, I can't reproduce the failure I had, but fixing the warnings
gcc issues when using uint32_t instead of int for cpu_get_tb_cpu_state
should be enough to make the change safe.  Note this doesn't really
belong to this patch set :-)


reply via email to

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