[RFC PATCH 0/3] arm64: Implement reliable stack trace

[Madhavan T. Venkataraman]

On 1/28/21 9:26 AM, Josh Poimboeuf wrote:
> 
> 
>>
>>> Then, the unwinder can check the functions it encounters in the stack trace and
>>> inform the caller if it found any no-FP functions. The caller of the unwinder can
>>> decide what he wants to do with that information.
>>>
>>> 	- the caller can ignore it
>>>
>>> 	- the caller can print the stack trace with a warning that no-FP functions
>>> 	  were found
>>>
>>> 	- if the caller is livepatch, the caller can retry until the no-FP functions
>>> 	  disappear from the stack trace. This way, we can have live patching even
>>> 	  when some of the functions in the kernel are no-FP.
>>>
>>> Does this make any sense? Is this acceptable? What are the pitfalls?
> 
> Why not just fix the reported no-FP functions?

I was not sure if all warnings can be fixed. For instance, some performance critical
functions may not want the extra overhead of the prolog and epilog. Also, as you
mentioned elsewhere, assembly code is often spaghetti code with multiple labels
and functions sharing code, etc. I am not sure that these can easily be fixed.

To prevent objtool from rejecting these, we have to find some way for objtool to
ignore them so it does not generate any warnings. Is this not correct? For x86,
did guys manage to fix every single warning? I am not familiar with the history
of this. So, I am just assuming.

> 
>>> If we can do this, the unwinder could detect cases such as:
>>
>>> - If gcc thinks that a function is a leaf function but the function contains
>>>   inline assembly code that calls another function.
>>
>>> - If a call to a function bounces through some intermediate code such as a
>>>   trampoline.
>>
>>> - etc.
>>
>>> For specific no-FP functions, the unwinder might be able to deduce the original
>>> caller. In these cases, the stack trace would still be reliable. For all the others,
>>> the stack trace would be considered unreliable.
>>
>> I'm not entirely sure I see the distinction from the current situation
>> here?
>>

Sorry. I should have been clear. If there are no-FP functions that cannot really be
fixed to objtool's satisfaction and objtool is made to ignore them, they may
still show up on the stack and hide their callers.

Madhavan