[lkml]   [2011]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod: Unknown relocation: 36
On Mon, 2011-01-17 at 22:35 -0800, David Miller wrote:
> From: Steven Rostedt <>
> Date: Mon, 17 Jan 2011 09:15:41 -0500
> > 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.
> Just take away all of the align directives, it should just work.

If that was the case, we would have never added it :-)

> If it doesn't, then we should investigate to find out the real reason
> why.

OK, we can remove it and I can see what breaks.

> The linker has no reason to add holes, and in fact if we are to believe
> the commit message for 86c38a31aa7f2dd6e74a262710bf8ebf7455acc5
> ("tracing: Fix ftrace_event_call alignment for use with gcc 4.5"), with
> gcc-4.x where x < 5, it did work even though some ftrace_event_call
> declarations lacked the align directive.
> If this align thing is so critical, why don't we need it for the
> exception table entries which live in the "__ex_table" section in the
> kernel? It's the same _exact_ kind of thing, and the asm sequence we
> use to populate it is identical to what GCC emits for the tracing
> object declarations in question.

But aren't the __ex_table entries just two words? Which would align
nicely regardless.

The ftrace_event_call is a relatively large structure, as it may end on
a 4 byte alignement, the linker may start the next section with more
space to get it back to a 8 byte alignment. This is assuming that x86_64
packs the array in 4 bytes.

Hmm, perhaps changing the alignment in would fix that.

Anyway, I'll revert that commit and see if I can break it again. If so,
then I'll look for other solutions.


-- Steve

 \ /
  Last update: 2011-01-18 18:33    [W:0.151 / U:2.452 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site