Re: [patch/RFA] multiarch INSTRUCTION_NULLIFIED

[Randolph Chung <randolph@tausq.org>]

> If, when resuming the inferior, a double step is required, 
> single_step_through_delay will do the job.

this is not possible to do in the general case though, because, sitting
on the current insn at pc, you cannot necessarily determine if the 
next insn will be nullified or not. (in the current example, the 
nullification is always applied, but it can be conditional on some 
computation being done)

> However, that doesn't solve the case of GDB encountering a frame 
> (inferior) that, be it through attach, cntrl-c, a signal, or a core 
> file, is already sitting on the above nullified instruction.  The 
> corefile case being expecially nasty - trying to get a corefile to step 
> off a nullified instruction won't get you very far :-).  I suspect that 
> the code will need to modify ``pc'' so that it either appears to be one 
> instruction behind (the "bv,n") or one instruction ahead (branch 
> destination) of what the registers indicate.

oh, are you saying that:
if we are looking at a corefile, and the current pc is sitting on a
nullified insn that belonged to the next function, that we may not be
able to do a backtrace correctly?

> It might also be useful to check the SPARC.  It has PC/NPC, delay slots, 
> and instruction nullification, so I'd expect similar problems.

ok, i'll see if i can find a sparc machine to try to reproduce this
problem there.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/