On Mon, 2011-01-17 at 10:22 +0000, Richard Mortimer wrote: > On Sun, 2011-01-16 at 22:07 -0800, David Miller wrote: > > From: David Miller <davem@xxxxxxxxxxxxx> > > Date: Sat, 15 Jan 2011 21:17:22 -0800 (PST) > > > > I think the problem we have here is that the _ftrace_events section is > > > not aligned sufficiently. That ".align 4" mnemonic is a good indication > > > of this. It should at least "8" on sparc64. > > > I noticed another potentially 64 bit unfriendly alignment on struct > tracepoint in include/linux/tracepoint.h. I don't think that the > alignment of 32 breaks anything but it does leave a 24 byte hole. I > don't know enough about tracing to know if that is necessary. > > struct tracepoint { > const char *name; /* Tracepoint name */ > int state; /* State. */ > void (*regfunc)(void); > void (*unregfunc)(void); > struct tracepoint_func *funcs; > } __attribute__((aligned(32))); /* > * Aligned on 32 bytes because it is > * globally visible and gcc happily > * align these on the structure size. > * Keep in sync with vmlinux.lds.h. > */ > > Note I spotted this when looking at some residual sparc64 relocation > issues when _ftrace_events alignment is changed to 8. I'll follow those > issues up in a separate email when I get time later today. I did some experiments looking at what happens when the include/trace/ftrace.h __aligned__(4) usages for _ftrace_events are changed to __aligned__(8). This causes the R_SPARC_UA64 relocations to go to R_SPARC_64 and gets rid of that particular issue. However it does not cause the R_SPARC_13 relocation records to go away. They still persist and the ones I've looked at are be related to uses of struct tracepoint that I mentioned earlier. I tried various different values of alignment for both __ftrace_events and struct tracepoint but nothing made the uses of R_SPARC_13 go away. As an example from drivers/scsi/scsi_error.c function scsi_eh_wakeup(). This has relocation records of 0000000000002be0 R_SPARC_HI22 __tracepoint_scsi_eh_wakeup 0000000000002be4 R_SPARC_LO10 __tracepoint_scsi_eh_wakeup 0000000000002be4 R_SPARC_13 *ABS*+0x0000000000000008 0000000000002bf4 R_SPARC_LO10 __tracepoint_scsi_eh_wakeup 0000000000002bf4 R_SPARC_13 *ABS*+0x0000000000000020 for the following assembly code sethi %hi(__tracepoint_scsi_eh_wakeup), %g1 !, tmp135 lduw [%g1+%lo(__tracepoint_scsi_eh_wakeup)+8], %g2 ! __tracepoint_scsi_eh_wakeup.state, cmp %g2, 0 ! __tracepoint_scsi_eh_wakeup.state, be,pt %icc, .LL454 nop ! ldx [%g1+%lo(__tracepoint_scsi_eh_wakeup)+32], %l0 !, it_func_ptr brz,pn %l0, .LL454 ! it_func_ptr, this corresponds to the first few lines of void scsi_eh_wakeup(struct Scsi_Host *shost) { if (shost->host_busy == shost->host_failed) { trace_scsi_eh_wakeup(shost); wake_up_process(shost->ehandler); SCSI_LOG_ERROR_RECOVERY(5, printk("Waking error handler thread\n")); } } If I try compiling with the -Os option removed from KBUILD_CFLAGS it produces a more traditional R_SPARC_HI22 and R_SPARC_LO10 output as shown below. So maybe there is a really need to add R_SPARC_13 support to the sparc64 module loader to allow for the optimizations that the compiler is making now. 00000000000001bc R_SPARC_HI22 __tracepoint_scsi_eh_wakeup 00000000000001c0 R_SPARC_LO10 __tracepoint_scsi_eh_wakeup 00000000000001dc R_SPARC_HI22 __tracepoint_scsi_eh_wakeup+0x0000000000000020 00000000000001e0 R_SPARC_LO10 __tracepoint_scsi_eh_wakeup+0x0000000000000020 ldx [%fp+2175], %g1 ! shost, tmp123 stx %g1, [%fp+2007] ! tmp123, shost sethi %hi(__tracepoint_scsi_eh_wakeup), %g1 !, tmp125 or %g1, %lo(__tracepoint_scsi_eh_wakeup), %g1 ! tmp125,, tmp124 ld [%g1+8], %g1 ! __tracepoint_scsi_eh_wakeup.state, D.32824 xor %g1, 0, %g1 ! D.32824,, tmp126 subcc %g0, %g1, %g0 !, tmp126 addx %g0, 0, %g1 !,, D.32823 brz %g1, .LL3 nop ! D.32822, sethi %hi(__tracepoint_scsi_eh_wakeup+32), %g1 !, tmp127 or %g1, %lo(__tracepoint_scsi_eh_wakeup+32), %g1 ! tmp127,, D.32820 ldx [%g1], %g1 !* D.32820, tmp128 stx %g1, [%fp+2015] ! tmp128, _________p1 Regards Richard -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html