On 1/28/21 9:26 AM, Josh Poimboeuf wrote:

quoted

quoted

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.

quoted

quoted

If we can do this, the unwinder could detect cases such as:

quoted

- If gcc thinks that a function is a leaf function but the function contains
  inline assembly code that calls another function.

quoted

- If a call to a function bounces through some intermediate code such as a
  trampoline.

quoted

- etc.

quoted

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel