[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201211084519.GT2414@hirez.programming.kicks-ass.net>
Date: Fri, 11 Dec 2020 09:45:19 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Nick Desaulniers <ndesaulniers@...gle.com>
Cc: Arnd Bergmann <arnd@...nel.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
clang-built-linux <clang-built-linux@...glegroups.com>
Subject: Re: objtool crashes with some clang produced .o files
On Thu, Dec 10, 2020 at 03:35:45PM -0800, Nick Desaulniers wrote:
> On Thu, Dec 3, 2020 at 5:56 AM Arnd Bergmann <arnd@...nel.org> wrote:
> >
> > I see occasional randconfig builds failing on x86 with clang-11
> > and clang-12 when objtool crashes with a segmentation fault.
> >
> > The simplest test case I managed to create is
> >
> > $ echo "__SCK__tp_func_cdev_update() { __SCT__tp_func_cdev_update(); }" > file.c
> So some instruction in .text that contained a relocation for, we could
> not determine a symbol for? I'm curious why we're even in this loop
> though, since we didn't do anything related to static calls...
No you did, you called a __SCT*() function, which is a
static-call-trampoline. objtool does indeed assume it then has a symbol
for the matching key, which should be guaranteed by the __ADDRESSABLE()
in __static_call().
>From linux/static_call.h:
/*
* __ADDRESSABLE() is used to ensure the key symbol doesn't get stripped from
* the symbol table so that objtool can reference it when it generates the
* .static_call_sites section.
*/
#define __static_call(name) \
({ \
__ADDRESSABLE(STATIC_CALL_KEY(name)); \
&STATIC_CALL_TRAMP(name); \
})
Let me go find a copy of clang-11..
Powered by blists - more mailing lists