On Thu, 4 Aug 2011, Richard Henderson wrote:
> This seems to do the trick for sim testing of sh-elf and cris-elf.
>
> I'm interested in advice re debugging experiences with delay slots.
> It seems like for calls there's no alternative but to have the unwind
> info be incorrect when stopped at the call insn itself.
>
> It also seems like we've similarly been generating unwind info that
> was incorrect for branches with frame-related insns in delay slots.
> Further, that by delaying the unwind info until after the sequence
> we can avoid that incorrectness.
>
> Have any of you experienced that incorrectness before, when debugging
> on your respective targets?

For calls, test crisv32-axis-elf; pre-v32 doesn't have
delay-slots for calls.  I can't claim to have done extensive
debugging on crisv32-* ... ok, blatant lie, but I mean, that
uses the debug info.  I can't remember complaints from any of
"my users" as I would probably automatically tell them from my
general experience: that debugging at any level above -O0 is
unusable.  (At least for the releases being used; 4.3 or so.)
I can have a more accurate and useful answer in two weeks...

But this in cris.md seems to answer "yes" for call insns, for
the unwind info experience (and thus the frame debug info):

;; We can't put prologue insns in call-insn delay-slots when
;; DWARF2 unwind info is emitted, because the unwinder matches the
;; address after the insn.  It must see the return address of a call at
;; a position at least *one byte after* the insn, or it'll think that
;; the insn hasn't been executed.  If the insn is in a delay-slot of a
;; call, it's just *exactly* after the insn.

(define_delay (eq_attr "slottable" "has_call_slot")
  [(and (eq_attr "slottable" "yes")
        (ior (eq (symbol_ref "RTX_FRAME_RELATED_P (insn)")
                 (const_int 0))
             (eq (symbol_ref "flag_exceptions")
                 (const_int 0))))
   (nil) (nil)])

I think as long as unwind info is correct when the call has
happened, I'm ok.  If it's incorrect just before the call is
executed, then it's at least no regression.  Asynchronous
exceptions?  Never heard of them. :)

brgds, H-P

Reply via email to