Hi,
I have to admit that the intention (when I wrote the code) of the __attribute__
((aligned(64))) on the typedef struct was to have elements properly sized.
I thought to remember that I did look at this attribute behavior before but
then again my memory is not as reliable as I wish for, so nothing like some
testing to find out.
struct A {
short f[3];
} __attribute__ ((aligned (64)));
struct A a[2];
sizeof(struct A) = 64, sizeof(a) = 128 for both GCC and CLANG.
This is the sort of behavior I was expecting.
typedef struct B {
short f[3];
} b_t __attribute__ ((aligned (64)));
b_t b[2];
Interestingly enough, when defining the typedef like above, GCC fails to
compile with:
error: alignment of array elements is greater than element size
sizeof(b_t) = 6 for CLANG and what it looks wrong to me is sizeof(b) = 64.
typedef struct C {
short f[3];
} __attribute__ ((aligned (64))) c_t;
c_t c[2];
sizeof(c_t) = 64, sizeof(c) = 128 for both GCC and CLANG.
As far as allocations from the heap, __attribute__ ((aligned(xxx))) should have
the desired effect.
That being said and even though it seems to behave as I thought it should, the
error GCC throws in one of the cases makes me wonder if we should not rely on
the compiler and just add mark fields to the struct to achieve the desired size.
Below is the link with some code to play around:
https://godbolt.org/g/7RDBQG
Regards,
Sergio
From: Radu Nicolau<mailto:radu.nico...@intel.com>
Sent: Friday 27 April 2018 10:34
To: Dave Barach (dbarach)<mailto:dbar...@cisco.com>; Florin
Coras<mailto:fcoras.li...@gmail.com>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] segfault due to movaps unaligned access
Thanks for looking into it!
In addition, If I understand correctly, using __attribute__((aligned(xxx))) on
structs that are only allocated from heap doesn’t actually do anything (but
sometimes confuse gcc into generating misaligned accesses).
From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
Sent: Thursday, April 26, 2018 5:08 PM
To: Nicolau, Radu <radu.nico...@intel.com>; Florin Coras
<fcoras.li...@gmail.com>
Cc: vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] segfault due to movaps unaligned access
Yes, it’s arguably a compiler bug.
But, it makes no sense to vec_validate_aligned(…), pool_get_aligned(…) etc.
objects whose size is not a multiple of the alignment request. Only the first
element will be aligned to the specified boundary.
__attribute__((aligned(xxx))) is not the same thing as ensuring that objects
are sized correctly.
D.
From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> On Behalf Of Radu Nicolau
Sent: Thursday, April 26, 2018 4:54 AM
To: Florin Coras <fcoras.li...@gmail.com<mailto:fcoras.li...@gmail.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] segfault due to movaps unaligned access
Hi Florin,
Thanks! The patch fixes the issue.
Any idea why is it happening?
Regards,
Radu
From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
[mailto:vpp-dev@lists.fd.io] On Behalf Of Florin Coras
Sent: Tuesday, April 24, 2018 11:25 PM
To: Nicolau, Radu <radu.nico...@intel.com<mailto:radu.nico...@intel.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] segfault due to movaps unaligned access
Hi Radu,
Making the crypto_worker_main_t a full cache line in size (see patch [1]) seems
to solve the issue. Could you confirm?
Florin
[1] https://gerrit.fd.io/r/#/c/12086/
On Apr 24, 2018, at 9:23 AM, Radu Nicolau
<radu.nico...@intel.com<mailto:radu.nico...@intel.com>> wrote:
Hello all,
We’re seeing a weird issue, that is a segfault that looks to be caused by a
movaps instruction that is trying to access an address that is not 16 byte
aligned.
The call originates from a vec_validate_init_empty_aligned that has the
argument aligned to 16 bytes.
I have seen something like this in the past, we couldn’t find a root cause and
considered it a GCC bug (version 5 then), but now it pops up again on version
7, so probably it isn’t.
Any idea? A snapshot of the gdb screen below.
gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
https://postimg.cc/image/9jy4p38at/
thanks and I will appreciate any help,
Radu
