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
