On Mon, 2011-01-17 at 22:35 -0800, David Miller wrote:
> From: Steven Rostedt <rostedt@xxxxxxxxxxx>
> 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 vmlinux.lds.h 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.
Thanks!
-- Steve
--
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
