In article <Pine.NEB.4.53.0304091151480.630@oor-wullie.mctavish.co.uk>,
Steve Woodford <scw@wasabisystems.com> wrote:

Hi Steve,

This is the first time I see an aligned attribute applied to a typedef.
This is usually applied to a variable instance. I can understand what
the intent is, i.e. to make all imask_t instances appropriately aligned,
but I would not be surprised, if the compiler just saw this as a request
to align all u_int32_t's. If that is the case, it should be fixed to do
the former.

christos
>Hi,
>
>While porting NetBSD to a powerpc platform, I stumbled across a bizarre
>problem which manifests itself most obviously by corrupting the output of
>ps(1). Matt Thomas has also reported this effect to me privately. I
>tracked this one down to the fact that sizeof(struct kinfo_proc2) is
>different for the kernel compared to userland built from the same
>source.
>
>Further investigation showed that the compiler was inserting unnecessary
>padding just before p_siglist in struct kinfo_proc2.
>
>After yet more digging, this turned out to be caused by an unrelated
>alignment attribute in arch/powerpc/marvell/marvell_intr.h:103 (which is
>visible to gcc only when _KERNEL is defined).
>
>For some reason, after gcc sees that alignment attribute, it seems to
>apply the same alignment to other u_int32_t arrays, hence the extra
>padding for p_siglist. (Note: I haven't verified how widespread this
>effect is elsewhere).
>
>The alignment attribute in that imask_t typedef is not strictly required
>as everywhere an imask_t is instanciated, it has an extra alignment
>qualifier anyway.
>
>Unless I'm completely off the mark, the effect of the imask_t typedef's
>alignment attribute should not be propagated elsewhere.
>
>Comments?
>
>Cheers, Steve
>
>-- 
>
>Wasabi Systems Inc. - The NetBSD Company - http://www.wasabisystems.com/
>