[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YBqPp53EM/E+o5TA@hirez.programming.kicks-ass.net>
Date: Wed, 3 Feb 2021 12:57:27 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: Nick Desaulniers <ndesaulniers@...gle.com>,
Julien Thierry <jthierry@...hat.com>,
Ard Biesheuvel <ardb@...nel.org>,
Mark Brown <broonie@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Kees Cook <keescook@...omium.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
linux-efi <linux-efi@...r.kernel.org>,
linux-hardening@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>,
Mark Rutland <mark.rutland@....com>,
Masahiro Yamada <masahiroy@...nel.org>,
Michal Marek <michal.lkml@...kovi.net>, raphael.gault@....com,
Will Deacon <will@...nel.org>,
clang-built-linux <clang-built-linux@...glegroups.com>,
Bill Wendling <morbo@...gle.com>, swine@...gle.com,
yonghyun@...gle.com
Subject: Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect
switch table on arm64
On Tue, Feb 02, 2021 at 06:14:14PM -0600, Josh Poimboeuf wrote:
> > Sure, but this is what production unwinders do, and they don't require
> > compiler plugins, right?
>
> What do you mean by "production unwinders"? Generally unwinders rely on
> either frame pointers or DWARF, but (without validation) those aren't
> robust enough for live patching in the kernel, so I'm not sure how this
> is relevant.
Not to mention that DWARF and consequently it's unders are horribly
large, complex and above all fragile things.
There's a reason ORC got invented, DWARF is simlpy unacceptable and
inadequate.
Now, one avenue that has been mentioned in the past, but I've not seen
recently, is to have objtool use DWARF as input to help it understand
the code. At least in userspace we can rely on DWARF libs. But I'm
fairly sure people aren't jumping up and down for having to always build
their kernel with DWARFs on, compile speed etc..
Powered by blists - more mailing lists