This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch/RFA] multiarch INSTRUCTION_NULLIFIED


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]