svn commit: r330338 - head/sys/amd64/amd64

[Bruce Evans]

On Sat, 10 Mar 2018, Bruce Evans wrote:

> On Fri, 9 Mar 2018, John Baldwin wrote:
>> 
>> I think you actually just want to replace Xfast_syscall with
>> fast_syscall_common.  Neither Xfast_syscall nor Xfast_syscall_pti call any
>> functions before jumping to the common label, so when unwinding from a 
>> system
>> call you should always get the common label.  (That is, I think we should
>> remove Xfast_syscall and Xfast_syscall_pti here.  Any stack trace that
>> happens to find those symbols during unwinding won't have a valid SYSCALL
>> frame to unwind.)
>
> No, it needs these symbols to decode the frame after reaching a point where
> the frame is actually set up.
>
> Also, in uncommitted fixes I add some decoding of the non-frame between
> the entry point and when the frame is set up.  Then the frame register
> ...

> Jumps and labels with names inside functions complicate things.  I think
> fast_syscall_common needs to be in the list too, and the many alltraps
> labels should have been there.  This will be more useful with my fix.
> The label calltrap has always been in the list.  This works right since
> the frame has been set up then -- IIRC it is the first place where the
> frame has been set up, and label it more for gdb than for ddb, and decode
> the frame for ddb (presumably gdb decodes the frame too).

Actually, internal labels like alltraps just break finding the entry
point.  Cross-jumping to such labels also breaks finding the entry
point.  The calltrap label is a work around for this problem -- it is
too hard to trace back to the entry point (e.g., Xpage) or even to
alltraps, so the single fake entry point calltrap is used.  Syscalls
and interrupts are more important, or at least easier to handle, so
the problem was avoided for them by not using cross jumps or too many
internal labels (though I don't like unnamed labels).  This is quite
broken for amd64 now.  Cross-jumps also complicate mcounting.  (The
non-traps are easier to handle since they are not multiplexed through
trap().  The multiplexing can be thought of as making all traps enter
at trap() with a trap code giving the trap number, so no label for the
entry point is needed.  The trap code is an arg, so it is printed in
the stack trace on i386.)

Bruce