From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932510AbdHYMWo (ORCPT ); Fri, 25 Aug 2017 08:22:44 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:41199 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754446AbdHYMWm (ORCPT ); Fri, 25 Aug 2017 08:22:42 -0400 Date: Fri, 25 Aug 2017 14:22:37 +0200 (CEST) From: Thomas Gleixner To: kbuild test robot cc: kbuild-all@01.org, linux-kernel@vger.kernel.org, tipbuild@zytor.com Subject: Re: [tip:WIP.x86/apic 40/43] arch/x86/kernel/irq.o:(__tracepoints+0x170): undefined reference to `trace_resched_ipi_reg' In-Reply-To: <201708251922.3W8rHNWi%fengguang.wu@intel.com> Message-ID: References: <201708251922.3W8rHNWi%fengguang.wu@intel.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 25 Aug 2017, kbuild test robot wrote: > Hi Thomas, > > It's probably a bug fix that unveils the link errors. > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/apic > head: 395b2c62edea5a2bb8a8786392feb12fae5917a7 > commit: 902f1bb88397dd6769c98b2177bbda134b3a1ef2 [40/43] x86/idt: Deinline setup functions > config: i386-randconfig-s0-201734 (attached as .config) > compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 > reproduce: > git checkout 902f1bb88397dd6769c98b2177bbda134b3a1ef2 > # save the attached .config to linux build tree > make ARCH=i386 > > All errors (new ones prefixed by >>): > > >> arch/x86/kernel/irq.o:(__tracepoints+0x170): undefined reference to `trace_resched_ipi_reg' > >> arch/x86/kernel/irq.o:(__tracepoints+0x174): undefined reference to `trace_resched_ipi_unreg' > arch/x86/kernel/irq.o:(__tracepoints+0x184): undefined reference to `trace_resched_ipi_reg' > arch/x86/kernel/irq.o:(__tracepoints+0x188): undefined reference to `trace_resched_ipi_unreg' > That link error is caused by the tracepoint code being stupid enough to generate tracepoint stuff in an object file whether they are used or not. The issue here is that the reschedule ipi tracepoint has an initializer function which is only compiled in when CONFIG_SMP=y. That tracepoint is not used in irq.o at all, but still the tracepoint macro hell generates something for it: objdump -t ../build-386/arch/x86/kernel/irq.o | grep resched 00000048 l O _ftrace_events 00000004 __event_reschedule_exit 00000a00 l O .data 0000004c event_reschedule_exit 0000004c l O _ftrace_events 00000004 __event_reschedule_entry 00000a60 l O .data 0000004c event_reschedule_entry 00000048 l O __tracepoints_ptrs 00000004 __tracepoint_ptr_reschedule_exit 00000188 l O __tracepoints_strings 00000010 __tpstrtab_reschedule_exit 0000004c l O __tracepoints_ptrs 00000004 __tracepoint_ptr_reschedule_entry 00000198 l O __tracepoints_strings 00000011 __tpstrtab_reschedule_entry 0000017c g O __tracepoints 00000014 __tracepoint_reschedule_entry 00000000 *UND* 00000000 trace_resched_ipi_reg 00000168 g O __tracepoints 00000014 __tracepoint_reschedule_exit 00000000 *UND* 00000000 trace_resched_ipi_unreg Brilliant stuff that. I'll hide the tracepoint behind a CONFIG_SMP ifdef for now. Thanks, tglx