On Wed, Jan 13, 2021 at 01:33:13PM -0600, Josh Poimboeuf wrote:

On Wed, Jan 13, 2021 at 04:57:43PM +0000, Mark Brown wrote:

quoted

From: Mark Rutland <mark.rutland@arm.com>
+There are several ways an architecture may identify kernel code which is deemed
+unreliable to unwind from, e.g.
+
+* Using metadata created by objtool, with such code annotated with
+  SYM_CODE_{START,END} or STACKFRAME_NON_STANDARD().

I'm not sure why SYM_CODE_{START,END} is mentioned here, but it doesn't
necessarily mean the code is unreliable, and objtool doesn't treat it as
such.  Its mention can probably be removed unless there was some other
point I'm missing.

Also, s/STACKFRAME/STACK_FRAME/

When I wrote this, I was under the impression that (for x86) code marked
as SYM_CODE_{START,END} wouldn't be considered as a function by objtool.
Specifically SYM_FUNC_END() marks the function with SYM_T_FUNC whereas
SYM_CODE_END() marks it with SYM_T_NONE, and IIRC I thought that objtool
only generated ORC for SYM_T_FUNC functions, and hence anything else
would be considered not unwindable due to the absence of ORC.

Just to check, is that understanding for x86 correct, or did I get that
wrong?

If that's right, it might be worth splitting this into two points, e.g.

| * Using metadata created by objtool, with such code annotated with
|   STACKFRAME_NON_STANDARD().
|
|
| * Using ELF symbol attributes, with such code annotated with
|   SYM_CODE_{START,END}, and not having a function type.

If that's wrong, I suspect there are latent issues here?

Thanks,
Mark.