On 12 November 2018 at 05:56, Josh Poimboeuf <jpoim...@redhat.com> wrote: > On Mon, Nov 12, 2018 at 05:39:38AM +0100, Ard Biesheuvel wrote: >> On 12 November 2018 at 04:07, Josh Poimboeuf <jpoim...@redhat.com> wrote: >> > On Sat, Nov 10, 2018 at 08:09:17AM -0500, Steven Rostedt wrote: >> >> On Sat, 10 Nov 2018 12:58:08 +0100 >> >> Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: >> >> >> >> >> >> > > The complaint is on: >> >> > > >> >> > > DEFINE_STATIC_CALL(__tp_func_##name, >> >> > > __tracepoint_iter_##name); >> >> > > >> >> > > And the previous definition is on: >> >> > > >> >> > > DECLARE_STATIC_CALL(__tp_func_##name, >> >> > > __tracepoint_iter_##name); \ >> >> > > >> >> > >> >> > Does the DECLARE really need the __ADDRESSABLE? Its purpose is to >> >> > ensure that symbols with static linkage are not optimized away, but >> >> > since the reference is from a header file, the symbol should have >> >> > external linkage anyway. >> > >> > Yes, DECLARE needs the __ADDRESSABLE. In the case where DECLARE >> > is used, but DEFINE is not, GCC strips the symbol. >> > >> >> I assume DECLARE() is intended for use in header files, and DEFINE() >> for source files, no? > > Right. > >> Doesn't that mean that whatever symbol __ADDRESSABLE() refers to >> should have external linkage, in which case it it addressable anyway? >> Or are we talking about some LTO / --gc-sections use case here? > > If the key is declared, but not used, GCC doesn't put the key's ELF > symbol in the binary's symbol table. That makes objtool's life harder, > because if the file has a call site, then objtool has to add the key > symbol to the symbol table, so that it can create a relocation (in the > call site table) which references the symbol. >
Ah, right. So this is specific to objtool rather than a generic issue. Should we perhaps wrap __ADDRESSABLE() into something else that resolves to a NOP unless on X86, and give it a clear name?