qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] target-mips: Output CP0.Config2-5 in the regist


From: Maciej W. Rozycki
Subject: Re: [Qemu-devel] [PATCH] target-mips: Output CP0.Config2-5 in the register dump
Date: Tue, 2 Dec 2014 11:37:33 +0000
User-agent: Alpine 1.10 (DEB 962 2008-03-14)

On Tue, 2 Dec 2014, Leon Alrae wrote:

> > @@ -19276,6 +19276,10 @@ void mips_cpu_dump_state(CPUState *cs, F
> >                  env->CP0_Status, env->CP0_Cause, env->CP0_EPC);
> >      cpu_fprintf(f, "    Config0 0x%08x Config1 0x%08x LLAddr 0x" 
> > TARGET_FMT_lx "\n",
> >                  env->CP0_Config0, env->CP0_Config1, env->lladdr);
> > +    cpu_fprintf(f, "    Config2 0x%08x Config3 0x%08x\n",
> > +                env->CP0_Config2, env->CP0_Config3);
> > +    cpu_fprintf(f, "    Config4 0x%08x Config5 0x%08x\n",
> > +                env->CP0_Config4, env->CP0_Config5);
> 
> Wouldn't it be better to order these registers for example by CP0
> Register and Select number rather than putting them at the end? I think
> it doesn't matter at the moment as there are just few registers printed
> out, but once we start adding more then probably we would like to avoid
> having them placed arbitrarily in the output.

 I placed the registers such that output renders in a well-formatted 
readable way.  Please note that we print 64-bit registers at the right 
side and I avoided intermixing 32-bit registers with 64-bit registers.

 I agree we might reformat output according to CP0 Register and Select 
numbers as for example our (Mentor's) GDB does in `info registers' (the 
change to dump all available CP0 registers in GDB hasn't made its way 
upstream yet, partially due to the XML register description issue I 
mentioned previously).  Hovewer we need to think how to format output in a 
readable way as the receiver will most often be a human being.

 I think deciding on a uniform register width, i.e. the native machine 
word size of the CPU, might help here, after all in the execution stream 
you can access them with DMFC0 on 64-bit processors and get the expected 
result (with "don't-care's" in the upper 32 bits).  The drawback is more 
screen space is used for data which can make it all harder to comprehend.  
For example I find the output of `info registers' produced by GDB on a 
64-bit target more difficult to process in my head than the corresponding 
output on a 32-bit target.  Maybe we can leave the upper 32 bits padded 
with spaces rather than zeros though.

  Maciej



reply via email to

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