* David Miller (davem@xxxxxxxxxxxxx) wrote: > From: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> > Date: Wed, 19 Jan 2011 00:08:45 -0500 > > > - No aligned() type attribute nor variable attribute. I get a crash on x86_64 > > (NULL pointer exception when executing __trace_add_event_call, the 5th call). > > __alignof__(struct ftrace_event_call) is worth 8. > > I think I figured it out. > > It's the static vs. non-static thing, or some other crazyness wrt. > how x86-64 implements it's alignment rules. > > GCC on x86-64 uses a completely different policy for aligning local > (ie. "static") data objects vs. globally visible ones, for one thing. > It also has different alignment policies for objects that are part > of an array vs. those which are not. > > On both counts, we're lying to the compiler, so maybe it's sort of our > fault. Yep, we're in strong agreement here. > > As far as GCC can see, the object is static and also not part of an > array or any other C construct for which things like this could matter > as long as the alignment it chooses meets the minimum alignment > requirements of the ABI. > > So it doesn't let us do this trick where we put the individual event > markers into a special section, yet mark it __used and static, then > later access them as if they were part of a globally visible array. > > If you look these static objects, they are emitted with a leading > ".align 32" directive. This is what screws everything up. Ah, yep, good way to identify the culprit. > > When the linker sees this, it aligns the start of every individual > "_ftrace_events" section, and that's where the "gaps" come from and > the crashes. OK (more to come in the following email response). Mathieu -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com -- 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
