On Tue, Feb 2, 2021 at 3:36 PM Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > > On Tue, Feb 02, 2021 at 02:33:38PM -0800, Nick Desaulniers wrote: > > On Mon, Feb 1, 2021 at 4:02 PM Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > > > > > > On Mon, Feb 01, 2021 at 03:17:40PM -0800, Nick Desaulniers wrote: > > > And yes, objtool has been pretty good at finding compiler bugs, so the > > > more coverage the better. > > > > The idea of rebuilding control flow from binary analysis and using > > > > that to find codegen bugs is a really cool idea (novel, even? idk), > > > > and I wish we had some analog for userspace binaries that could > > > > perform similar checks. > > > > > > Objtool is generic in many ways -- in fact I recently heard from a PhD > > > candidate who used it successfully on another kernel for an ORC > > > unwinder. > > > > That's pretty cool! Reuse outside the initial context is always a > > good sign that something was designed right. > > So basically you're saying objtool is both useful and well-designed. I > will quote you on that! Haha, all I'm saying is that while I'm not proud that it did find bugs in LLVM (and I do have existing bugs found by it to fix on my plate), I don't see who else or how else those would have been spotted, and I can appreciate that. I think the tools given to us are broken (by design, perhaps), so anything that can help us spot issues might help our code live longer than we do. I also think that there's room for improvement and experimentation in debug info formats, though there is currently a proliferation to support. Live patching and eBPF seem to have some functional overlap IIUC, strengths/weaknesses, and their own unique debug info formats to go with it. Supporting each one does require some level of toolchain support or coordination (or complexity, even). -- Thanks, ~Nick Desaulniers
