On Wed, May 10, 2017 at 10:15:09AM +0200, Jiri Slaby 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, > > I second this. Inventing a new format like this mostly ends up with > using the standard one after several iterations. One cannot think of all > the consequences and needs while proposing a new one. > > The memory footprint is ~2M for average vmlinux. And people who need to > access: > * either need it frequently -- those do not need performance (LOCKDEP, > KASAN, or other debug builds) > * or are in the middle of WARNING, BUG, crash, panic or such and this is > not that often... > > And we would need *both*. The limited proprietary one in some sort of > .kernel_eh_frame, and DWARF cfis in .debug_frame for tools like crash, > gdb and so on. I don't think so. DWARF CFI is optimized for size. My proposal is to take the same data (or some subset of it) and reformat it to optimize for simplicity. If, for some reason, we ended up needing *all* the original DWARF data, we could still have it in the simpler format. In that case it might end up being 8M instead of 2M :-) But I don't see that being possible. -- Josh -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
