Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf)

From: Ingo Molnar
Date: Wed Jul 12 2017 - 04:27:23 EST



* Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:

> The biggest change is that undwarf was renamed to ORC. Here's the
> relevant explanation from the docs:
>
> Etymology
> ---------
>
> Orcs, fearsome creatures of medieval folklore, are the Dwarves' natural
> enemies. Similarly, the ORC unwinder was created in opposition to the
> complexity and slowness of DWARF.
>
> "Although Orcs rarely consider multiple solutions to a problem, they do
> excel at getting things done because they are creatures of action, not
> thought." [3] Similarly, unlike the esoteric DWARF unwinder, the
> veracious ORC unwinder wastes no time or siloconic effort decoding
> variable-length zero-extended unsigned-integer byte-coded
> state-machine-based debug information entries.
>
> Similar to how Orcs frequently unravel the well-intentioned plans of
> their adversaries, the ORC unwinder frequently unravels stacks with
> brutal, unyielding efficiency.
>
> ORC stands for Oops Rewind Capability.

Perfect naming!

(ORC might also stand for "Optimized Rewind Capability".)

> Create a new "ORC" unwinder, enabled by CONFIG_ORC_UNWINDER, and plug it
> into the x86 unwinder framework. Objtool is used to generate the ORC
> debuginfo. The ORC debuginfo format is basically a simplified version
> of DWARF CFI. More details below.

BTW., we should perhaps consolidate our unwinder related Kconfig space,
hierarchically:

CONFIG_UNWINDER
CONFIG_UNWINDER_ORC
CONFIG_UNWINDER_FRAME_POINTERS

Note that as a side effect it would be a valid small systems build option to have
no unwinder at all, if CONFIG_EXPERT=y is set and such: !CONFIG_UNWINDER=n would
be a sibling to !CONFIG_BUG.

CONFIG_FRAME_POINTERS et al would be left for architectures where it has a meaning
beyond backtrace generation. (Not sure whether there's any such architectures.)

> The unwinder works well in my testing. It unwinds through interrupts,
> exceptions, and preemption, with and without frame pointers, across
> aligned stacks and dynamically allocated stacks. If something goes
> wrong during an oops, it successfully falls back to printing the '?'
> entries just like the frame pointer unwinder.

Ok, I'll start applying your patches after -rc1, unless anyone objects.

> The ORC data format does have a few downsides compared to DWARF. The
> ORC unwind tables take up ~1MB more memory than DWARF eh_frame tables.

Could we also write this in percentage, not absolute RAM size - i.e. ORC unwind
tables take 30% more RAM (+0.7 MB on an x86 defconfig kernel) than DWARF eh_frame
tables.

Thanks,

Ingo