在 2013-04-24三的 08:28 +0100，Peter Maydell写道：
> On 24 April 2013 08:15, li guang <lig.f...@cn.fujitsu.com> wrote:
> > 在 2013-04-24三的 08:05 +0100，Peter Maydell写道：
> >> On 24 April 2013 02:48, liguang <lig.f...@cn.fujitsu.com> wrote:
> >> > Signed-off-by: liguang <lig.f...@cn.fujitsu.com>
> >>
> >> I'm afraid this is definitely wrong. It has a less than
> >> helpful name, but cs_base is actually just "another 32/64 bits
> >> of state that the target can use to distinguish translation
> >> blocks", and some non-x86 targets do use it. For instance:
> >
> > only sparc use it as a tmp buffer for pc.
>
> And x86 uses it. And tomorrow anybody could submit a patch
> to another target which makes use of it, if they find they
> need to do something and there's not enough room left in
> 'flags'. It's a generic mechanism which happens to be used
> by two targets today.
I think even others want to use something like you said,
it should not 'cs_base', or, it's a bad name.
>
> >> > --- a/target-sparc/cpu.h
> >> > +++ b/target-sparc/cpu.h
> >> > @@ -715,7 +715,7 @@ trap_state* cpu_tsptr(CPUSPARCState* env);
> >> > #define TB_FLAG_AM_ENABLED (1 << 5)
> >> >
> >> > static inline void cpu_get_tb_cpu_state(CPUSPARCState *env,
> >> > target_ulong *pc,
> >> > - target_ulong *cs_base, int
> >> > *flags)
> >> > + int *flags)
> >> > {
> >> > *pc = env->pc;
> >> > *cs_base = env->npc;
> >>
> >> ...surely this doesn't even compile after your changes?
> >>
> >
> > seems no problem for me.
>
> You clearly have a problem with your compile and test
> process then, because it is clear from the patch that
> you've removed the cs_base argument from this function
> but the function still has a use of 'cs_base' in it.
???, sorry, where do I miss 'cs_base' removing?
>
> -- PMM
