On Thu, Nov 8, 2018 at 1:31 PM Cyrill Gorcunov <gorcunov@xxxxxxxxx> wrote:
>
> On Thu, Nov 08, 2018 at 01:22:54PM -0800, Andy Lutomirski wrote:
> > > >
> > > > Why are these __packed? It seems like it'll generate bad code for no
> > > > obvious purpose.
> > >
> > > That prevents any possibility that the compiler will insert padding, although in
> > > 64-bit kernel this should not happen to either struct. Also all xstate
> > > components here are packed.
> > >
> >
> > They both seem like bugs, perhaps. As I understand it, __packed
> > removes padding, but it also forces the compiler to expect the fields
> > to be unaligned even if they are actually aligned.
>
> How is that? Andy, mind to point where you get that this
> attribute forces compiler to make such assumption?
It's from memory. But gcc seems to agree with me I compiled this:
struct foo {
int x;
} __attribute__((packed));
int read_foo(struct foo *f)
{
return f->x;
}
int align_of_foo_x(struct foo *f)
{
return __alignof__(f->x);
}
Compiling with -O2 gives:
.globl read_foo
.type read_foo, @function
read_foo:
movl (%rdi), %eax
ret
.size read_foo, .-read_foo
.p2align 4,,15
.globl align_of_foo_x
.type align_of_foo_x, @function
align_of_foo_x:
movl $1, %eax
ret
.size align_of_foo_x, .-align_of_foo_x
So gcc thinks that the x field is one-byte-aligned, but the code is
okay (at least in this instance) on x86.
Building for armv5 gives:
.type read_foo, %function
read_foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldrb r3, [r0] @ zero_extendqisi2
ldrb r1, [r0, #1] @ zero_extendqisi2
ldrb r2, [r0, #2] @ zero_extendqisi2
orr r3, r3, r1, lsl #8
ldrb r0, [r0, #3] @ zero_extendqisi2
orr r3, r3, r2, lsl #16
orr r0, r3, r0, lsl #24
bx lr
.size read_foo, .-read_foo
.align 2
.global align_of_foo_x
.syntax unified
.arm
.fpu vfpv3-d16
.type align_of_foo_x, %function
So I'm pretty sure I'm right.
