Re: [patch/RFA] multiarch INSTRUCTION_NULLIFIED

[Andrew Cagney <cagney@gnu.org>]

Randolph Chung wrote:
>>Is it possible to create a core file with the PC sitting on the 
>>nullified instruction, and if such a beast is created, how can GDB 
>>correctly handle it - GDB clearly can't single step the core file.  If 
>>that problem is solved, this method becomes redundant.
> 
> 
> what do you mean? this fix is in the handling of inferior events, so
> it doesn't apply to core files anyway, right?

Right.

> what case with core files
> do you think needs to be correctly handled?

The underlying problem that you described:

> i did some more investigations.... turns out this is not a cosmetic
> piece of code at all  :) 
> 
> suppose we have a function that ended with a branch-with-nullify-next
> instruction back to the caller. if you did a "step" on the branch, and
> we don't skip the nullified instruction, we would end up on the
> nullified instruction which actually belongs to the next function.
> 
> for example:
> 
> Dump of assembler code for function call_with_trampolines:
> 0x0001217c <call_with_trampolines+0>:   copy r3,r1
> 0x00012180 <call_with_trampolines+4>:   copy sp,r3
> 0x00012184 <call_with_trampolines+8>:   stw,ma r1,40(,sp)
> 0x00012188 <call_with_trampolines+12>:  ldi -28,r19
> 0x0001218c <call_with_trampolines+16>:  fstd fr5,r19(,r3)
> 0x00012190 <call_with_trampolines+20>:  ldi -28,r19
> 0x00012194 <call_with_trampolines+24>:  fldd r19(,r3),fr22
> 0x00012198 <call_with_trampolines+28>:  fcpy,dbl fr22,fr4
> 0x0001219c <call_with_trampolines+32>:  ldo 40(r3),sp
> 0x000121a0 <call_with_trampolines+36>:  ldw,mb -40(,sp),r3
> 0x000121a4 <call_with_trampolines+40>:  bv,n r0(rp)
> End of assembler dump.
> (gdb) disassemble 0x121a8
> Dump of assembler code for function marker_indirect_call:
> 0x000121a8 <marker_indirect_call+0>:    copy r3,r1
> 0x000121ac <marker_indirect_call+4>:    copy sp,r3
> 0x000121b0 <marker_indirect_call+8>:    stw,ma r1,40(,sp)
> 0x000121b4 <marker_indirect_call+12>:   ldo 40(r3),sp
> 0x000121b8 <marker_indirect_call+16>:   ldw,mb -40(,sp),r3
> 0x000121bc <marker_indirect_call+20>:   bv,n r0(rp)
> 
> if we are at 0x121a4, and we do a step, it will stop at
> "marker_indirect_call" instead of back at the caller of
> "call_with_trampolines". since the insn at 0x121a8 is not actually
> executed in this call sequence, the correct thing to do is to blindly
> step past the nullified instruction before we make any decision on what
> to do.

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

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.

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

Andrew