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 <r...@twiddle.net> 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 #define ARM_TBFLAG_AARCH64_STATE_SHIFT 31 #define ARM_TBFLAG_AARCH64_STATE_MASK (1U << ARM_TBFLAG_AARCH64_STATE_SHIFT) So, I would certainly be ok switching everything to use uint32_t over int. r~
