Re: [patch/RFA] multiarch INSTRUCTION_NULLIFIED

Andrew Cagney
2004-11-29T15:12:31Z

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