* Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > One instance of the structure would exist for each time the stack > pointer changes, e.g. for every function entry, push/pop, and rsp > add/subtract. The data could be assembled and sorted offline, possibly > derived from DWARF, or more likely, generated by objtool. After doing > some rough calculations, I think the section size would be comparable to > the sizes of the DWARF .eh_frame sections it would replace. That's something I've been thinking about as well: if objtool generates the unwinder data structures then the kernel is not directly exposed to tooling bugs anymore. A fair chunk of the fragility of DWARF comes from the fact that it's generated by a tool chain that we cannot fix as part of the kernel project. If GCC generates crap debuginfo, and GDB happens to work with it but the kernel not, we'll have to work it around in the kernel. If GCC starts bloating debuginfo in the future we are screwed as well, etc. If objtool generates debuginfo then it's _our_ responsibility to have sane unwinder info and we obviously manage its structure and size as well. Win-win. The unwinder itself should still do sanity checks, etc. (like all good debugging infrastructure code) - but the nature of the kernel's exposure to tool chain details changes in a very fundamental way. So yes, I think this is a very good idea, assuming it works in practice! ;-) Thanks, Ingo -- 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
