Re: [Xen-devel] [PATCH v2 2/2] x86/traps: widen condition for logging top-of-stack

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 17/06/2019 09:13, Jan Beulich wrote:
> Despite -fno-omit-frame-pointer the compiler may omit the frame pointer,
> often for relatively simple leaf functions.

Actually, the problem is more widespread than this.  For every function,
there is a non-zero quantity of time between the function starting and
the frame pointer being set up.

However, half of this time is spent with the old %rbp on the top of the
stack, so won't benefit from these changes.

> (To give a specific example,
> the case I've run into this with is _pci_hide_device() and gcc 8.
> Interestingly the even more simple neighboring iommu_has_feature() does
> get a frame pointer set up, around just a single instruction. But this
> may be a result of the size-of-asm() effects discussed elsewhere.)
>
> Log the top-of-stack value if it looks valid _or_ if RIP looks invalid.

This far, I'm happy with.

> Also annotate non-frame-pointer-based stack trace entries with a
> question mark, to signal clearly that any one of them may not actually
> be part of the call stack.

I'm still opposed to this.  The introduction of ? does more harm than
good IMO, because it simply can't be trusted.

Stack traces are not guaranteed-accurate, even with frame pointers
enabled.  The only thing we can say for certain in any trace is where
%rip points.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel