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.
>> > --- 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.
-- PMM
