From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751492AbcCKJWN (ORCPT ); Fri, 11 Mar 2016 04:22:13 -0500 Received: from metis.ext.4.pengutronix.de ([92.198.50.35]:48088 "EHLO metis.ext.4.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750803AbcCKJWD (ORCPT ); Fri, 11 Mar 2016 04:22:03 -0500 Date: Fri, 11 Mar 2016 10:21:59 +0100 From: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= To: Marc Kleine-Budde Cc: linux-kernel@vger.kernel.org, "Steven Rostedt (Red Hat)" , ptx kernel Subject: Re: dynamic ftrace/recordmcount.c problem on ARMv5 Message-ID: <20160311092159.GA1781@pengutronix.de> References: <56961010.6000806@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56961010.6000806@pengutronix.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c0 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Wed, Jan 13, 2016 at 09:51:28AM +0100, Marc Kleine-Budde wrote: > Hello, > > I'm on a ARMv5 (freescale mx25) and seeing this ftrace bug during bootup: > > > [ 0.059235] ------------[ cut here ]------------ > > [ 0.059449] WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:1938 ftrace_bug+0x210/0x2c8() > > [ 0.059645] Modules linked in: > > [ 0.059780] CPU: 0 PID: 0 Comm: swapper Not tainted 4.0.9-20151211-1-g45dbe7d2c077 #1 > > [ 0.059966] Hardware name: Freescale i.MX25 (Device Tree Support) > > [ 0.060157] [<8000f494>] (unwind_backtrace) from [<8000ce3c>] (show_stack+0x20/0x24) > > [ 0.060396] [<8000ce3c>] (show_stack) from [<8041ea68>] (dump_stack+0x20/0x28) > > [ 0.060630] [<8041ea68>] (dump_stack) from [<8001a74c>] (warn_slowpath_common+0x88/0xc0) > > [ 0.060853] [<8001a74c>] (warn_slowpath_common) from [<8001a840>] (warn_slowpath_null+0x2c/0x34) > > [ 0.061091] [<8001a840>] (warn_slowpath_null) from [<80083748>] (ftrace_bug+0x210/0x2c8) > > [ 0.061332] [<80083748>] (ftrace_bug) from [<80083bb8>] (ftrace_process_locs+0x330/0x6f0) > > [ 0.061576] [<80083bb8>] (ftrace_process_locs) from [<805bdc84>] (ftrace_init+0x8c/0x14c) > > [ 0.061815] [<805bdc84>] (ftrace_init) from [<805b0c80>] (start_kernel+0x33c/0x3b4) > > [ 0.062039] [<805b0c80>] (start_kernel) from [<80008040>] (0x80008040) > > [ 0.062238] ---[ end trace cb88537fdc8fa200 ]--- > > [ 0.062364] ftrace failed to modify [<8000c7d8>] walk_stackframe+0x24/0x44 > > [ 0.062544] actual: 16:ff:2f:e1 > > [ 0.062702] ftrace record flags: 0 > > [ 0.062803] (0) expected tramp: 8000e864 > > The problem is that walk_stackframe ends up in the __mcount_loc section, > although it has a "notrace" attribute: Not having much clue about elf and stuff, but being hit by this problem I added some debug output to recordmcount.c and found that sift_rel_mcount (aka sift32_rel_mcount) loops over .rel.text which looks as follows for me: $ readelf -R .rel.text arch/arm/kernel/stacktrace.o ... Relocation section '.rel.text' at offset 0xb5c contains 15 entries: Offset Info Type Sym.Value Sym. Name 0000001c 00000028 R_ARM_V4BX 0000002c 00001d1c R_ARM_CALL 00000000 unwind_frame 00000044 00001f1c R_ARM_CALL 00000000 __gnu_mcount_nc 00000104 0000201c R_ARM_CALL 00000000 in_sched_functions 00000118 00002102 R_ARM_ABS32 00000000 __exception_text_start 0000011c 00002202 R_ARM_ABS32 00000000 __exception_text_end 00000130 00001f1c R_ARM_CALL 00000000 __gnu_mcount_nc 00000194 00001c1c R_ARM_CALL 00000000 walk_stackframe 000001e0 00000902 R_ARM_ABS32 0000003c save_trace 000001e4 00000c02 R_ARM_ABS32 00000120 __save_stack_trace 000001ec 00001f1c R_ARM_CALL 00000000 __gnu_mcount_nc 00000218 00001f1c R_ARM_CALL 00000000 __gnu_mcount_nc 00000260 00001c1c R_ARM_CALL 00000000 walk_stackframe 0000028c 00000902 R_ARM_ABS32 0000003c save_trace 00000294 00001f1c R_ARM_CALL 00000000 __gnu_mcount_nc ... and the unwanted entry in __mcount_loc is generated from the first line which isn't a call, but just the information that there is a bx call that needs a fixup for ARMv4 machines (that don't support the bx instruction). For this entry get_mcountsym returns 0. recordmcount.pl only operates on R_ARM_(CALL|PC24|THM_CALL) types for ARM and so does it right. I don't know how to fix recordmcount.[ch], but maybe this is enough info to allow someone more knowledgeable to fix it. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |