Re: [patch/RFA] multiarch INSTRUCTION_NULLIFIED

[Andrew Cagney <cagney at gnu dot org>]

Randolph Chung wrote:
> > 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)

I'm not sure what you mean.  What you describe sounds like the old 
STEP_SKIPS_DELAY logic - a test on the _next_ instruction.  The new 
logic instead:

# Return non-zero if the processor is executing a delay slot and a
# further single-step is needed before the instruction finishes.
M::int:single_step_through_delay:struct frame_info *frame:frame

checks to see if the _last_ instruction put us into a delay slot.

(The MIPS code, which is technically implementing STEP_SKIPS_DELAY, 
works because when in a delay slot the PC still points at the branch 
instruction.  A fixme would be to change the mips code to instead test 
the delay-slot bit.).

> > 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?

Yes, and more to the point INSTRUCTION_NULLIFIED can't help here.  On 
the other hand, if this case is made to work INSTRUCTION_NULLIFIED is 
redundant.

However, the first question is: can such a corefile be created?  Given 
that GDB can single step an inferior into such a state, I think it can.

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

One thing to check is for isif the SPARC requires padding between functions?

--

If you want, add a DEPRECATED_INSTRUCTION_NULLIFIED to the architecture 
vector and have the PA-RISC use that.  While a sideways step, it lets 
you advance what I'm assuming is the more immediate objective of 
cleaning out PA's tm*.h files and making it pure multi-arch.

Andrew