Re: [patch/RFA] multiarch INSTRUCTION_NULLIFIED

Andrew Cagney
2004-12-01T23:32:24Z

Randolph Chung wrote:
>>Anyway, trying modifying gdbarch_read_pc and unwind_pc (I suspect you
>>need to modify both - which is a bug) to read something like:
>>
>> if (instruction nullified)
>> return next-pc
>> else
>> return this-pc
>
>
> i did s/next-pc/prev-pc/ instead... still seems a bit hacky to me, but
> it does seem to work.

> @@ -1049,7 +1089,17 @@ hppa_target_read_pc (ptid_t ptid)
> if (flags & 2)
> return read_register_pid (31, ptid) & ~0x3;
>
> - return read_register_pid (HPPA_PCOQ_HEAD_REGNUM, ptid) & ~0x3;
> + pc = read_register_pid (HPPA_PCOQ_HEAD_REGNUM, ptid) & ~0x3;
> +
> + /* If the current instruction is nullified, then we are effectively
> + still executing the previous instruction. Pretend we are still
> + there. This is needed when single stepping; if the nullified instruction
> + is on a different line, we don't want gdb to think we've stepped onto
> + that line. */
> + if (ipsw & 0x00200000)
> + pc -= 4;
> +
> + return pc;
> }

On the SPARC architecture you can do things like:

branch foo
branch bar

which leads to more warped combinations such as (assuming I've got my
diagram right):

f+0: branch x+c
f+4: branch x+8

x+0: branch e+4
x+4: branch e+0
x+8: branch x+0
x+c: branch,annulled x+4

and I'm fairly sure that results in:

f+0 f+4 [x+c]
f+4 x+c [x+8]
x+c --- [x+4]
--- x+4 [x+8] <-------- {npc+4}
x+4 x+8 [e+0]
x+8 e+0 [x+0]
e+0 x+0 ....

and hence the ``---'' anulled instruction at x+8 has a prev-pc of x+c
(pc+4) and not x+4 (pc-4).

This is why I was thinking that next-pc is better (but the above could
be wrong - my sparc is very very rusty :-().

Either way, yes ok (and thanks!)

Andrew

PS: No it's not a hack, XXX_pc projects the hardware onto an idealized
machine, there are always perverse edge cases.

PPS: A gdb.arch/ addition to tickle the basic edge case would be a
helpful way of capturing this knowledge.