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

[Josh Poimboeuf]

On Wed, Jul 12, 2017 at 10:27:10AM +0200, Ingo Molnar wrote:
> > 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.

So is the idea that CONFIG_UNWINDER=n means "use the 'guess' unwinder"?
Or should it mean that the unwind API isn't available?

Without frame pointers and orc, it defaults to the 'guess' unwinder, for
which the only overhead is a tiny amount of code.  It's still
technically considered an unwinder because it plugs into the unwind
interfaces (unwind_start(), unwind_next_frame(), etc) and is used for
things like /proc/<pid>/stack.

So I'm not really sure CONFIG_UNWINDER=n would make sense.  Maybe there
should just be a multiple-choice where you have to choose one of
CONFIG_UNWINDER_{ORC,FRAME_POINTER,GUESS}.

> 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.)

Well, on x86, hardened usercopy relies on frame pointers, but not the
unwinder.  It does the frame pointer walk manually to avoid the full
unwinder overhead.  See arch_within_stack_frames().

> > 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.

Thank you Ingo!

> > 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.

Ok, how about:

  "Orc unwind tables take up ~50% more RAM (+1.3MB on an x86 defconfig
  kernel) than DWARF eh_frame tables."

(My previous 1MB number was from my distro-based config, and it also
forgot to take into account the fast lookup table (".orc_lookup")).

-- 
Josh