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

["Jan Beulich" <JBeulich@suse.com>]

>>> On 07.06.19 at 20:01, <andrew.cooper3@citrix.com> wrote:
> 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.

So what do you suggest instead? Somehow we should mark slots
that are more guesses than actually derived.

> Porting Xen to use objtool would be a definite improvement, but cannot
> guard against unexpected %rbp corruption and the EFI case.

I'm not sure about "definite", but I think I see your point. Personally
I continue to believe that programmer (assembly code) and compiler
(C code) attached unwind annotations are the better model.

Jan



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