[RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64
ndesaulniers at google.com
Tue Feb 2 18:52:04 EST 2021
On Tue, Feb 2, 2021 at 3:36 PM Josh Poimboeuf <jpoimboe at redhat.com> 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 at redhat.com> 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).
More information about the linux-arm-kernel