Re: dynamic ftrace/recordmcount.c problem on ARMv5

[Namhyung Kim]

Hi,

On Fri, Mar 11, 2016 at 10:21:59AM +0100, Uwe Kleine-KÃnig wrote:
> 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.

Hmm.. that means we need to check the reloc types?  It seems the
binutils treats R_ARM_THM_PC22 as R_ARM_THM_CALL.

in /usr/include/elf.h:
#define R_ARM_SBREL32	9
#define R_ARM_THM_PC22	10	/* PC relative 24 bit (Thumb32 BL).  */
#define R_ARM_THM_PC8	11	/* PC relative & 0x3FC

in binutils-gdb/include/elf/arm.h:
  RELOC_NUMBER (R_ARM_SBREL32,	      9)
  RELOC_NUMBER (R_ARM_THM_CALL,       10)
  RELOC_NUMBER (R_ARM_THM_PC8,	      11)


So following patch (untested) works for you?

Thanks,
Namhyung



diff --git a/scripts/recordmcount.c b/scripts/recordmcount.c
index e167592793a7..dcc7896dce25 100644
--- a/scripts/recordmcount.c
+++ b/scripts/recordmcount.c
@@ -398,6 +398,20 @@ static void MIPS64_r_info(Elf64_Rel *const rp, unsigned sym, unsigned type)
 	}).r_info;
 }
 
+static int ARM_is_fake_mcount(Elf32_Rel const *rp)
+{
+	unsigned r_type = ELF32_R_TYPE(w(rp->r_info));
+
+	switch (r_type) {
+	case R_ARM_CALL:
+	case R_ARM_PC24:
+	case R_ARM_THM_PC22:
+		return 0;
+	default:
+		return 1;
+	}
+}
+
 static void
 do_file(char const *const fname)
 {
@@ -454,6 +468,7 @@ do_file(char const *const fname)
 		break;
 	case EM_ARM:	 reltype = R_ARM_ABS32;
 			 altmcount = "__gnu_mcount_nc";
+			 is_fake_mcount32 = ARM_is_fake_mcount;
 			 break;
 	case EM_AARCH64:
 			reltype = R_AARCH64_ABS64;