Messages in this thread | | | From | "H.J. Lu" <> | Date | Tue, 9 May 2017 09:46:08 -0700 | Subject | Re: [PATCH 7/7] DWARF: add the config option |
| |
On Tue, May 9, 2017 at 7:58 AM, Josh Poimboeuf <jpoimboe@redhat.com> wrote: > On Tue, May 09, 2017 at 03:00:45AM -0700, hpa@zytor.com wrote: >> I'm, ahem, highly skeptical to creating our own unwinding data format >> unless there is *documented, supported, and tested* way to force the >> compiler to *automatically* fall back to frame pointers any time there >> may be complexity involved, which at a very minimum includes any kind >> of data-dependent manipulation of the stack pointer. > > That would be nice. But isn't falling back to a frame pointer (or > another callee-saved reg or a stack location) already needed in such > cases? Otherwise how could DWARF unwinding work? > >> Otherwise you will have to fail the kernel build when your static tool >> runs into instruction sequences it can't deal with, but the compiler >> may generate them - boom. > > Failing the build is harsh, we could just warn about it and skip the > data for the affected function(s). > > BTW, there is another option. Instead of generating the data from > scratch, we could just convert gcc's DWARF CFI to the format we need. > > However that wouldn't solve the problems we have with the holes and > inaccuracies in DWARF from our hand-annotated asm, inline asm, and > special sections (extable, alternatives, etc). We'd still have to rely > on objtool for that, so we'd still be in the same boat of needing > objtool to be able to follow gcc code paths.
CFI directives are documented in GNU assembler manual. They store unwind info in .eh_frame section. They work well with assembly codes in glibc. But I don't know how well they work with kernel unwind.
> So yes, it sucks that objtool needs to work for unwinding to work. But > if we want decent DWARF-esque unwinding, I don't see any way around > that due to the low-level nature of the kernel. > >> Worse, your tool will not even recognize the problem and you're in a >> worse place than when you started. > > We could have a runtime NMI-based stack checker which ensures it can > always unwind to the bottom of the stack. Over time this would > hopefully provide full validation of the unwinder data and > functionality. > > -- > Josh
-- H.J.
| |