Subject: Re: Weird alignment bug on gcc/powerpc
To: None <email@example.com>
From: Christos Zoulas <firstname.lastname@example.org>
Date: 04/09/2003 12:58:47
In article <Pine.NEB.email@example.com>,
Steve Woodford <firstname.lastname@example.org> wrote:
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
>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
>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
>Unless I'm completely off the mark, the effect of the imask_t typedef's
>alignment attribute should not be propagated elsewhere.
>Wasabi Systems Inc. - The NetBSD Company - http://www.wasabisystems.com/