Re: Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod:Unknown relocation: 36

[Steven Rostedt]

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.

Again, this is to help the linker keep arrays in tacked. Tracepoints are
allocated into the tracepoint section, and then read like an array. If
the linker adds holes as it links sections into one big one, then the
reading of the array breaks.

We either need to compact it (with the align(4)) which is undesirable,
or add our own holes like the above does.

-- Steve



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/