On Wed, May 10, 2017 at 6:09 AM, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > 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. There is a compact EH for MIPS: https://github.com/itanium-cxx-abi/cxx-abi/blob/master/MIPSCompactEH.pdf It can be extended to other targets. -- H.J. -- 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
