On 31/05/2019 10:22, Jan Beulich wrote: > Despite -fno-omit-frame-pointer the compiler may omit the frame pointer, > often for relatively simple leaf functions. (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. > > 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 very specifically didn't do that before, because it give the false impression that when a question mark isn't present, the logging line is accurate. This is not true for %rbp corruption, asm blocks which don't respect the frame pointer ABI (arguably also corruption), any fault raised from within an EFI call. Porting Xen to use objtool would be a definite improvement, but cannot guard against unexpected %rbp corruption and the EFI case. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
