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
On 27 April 2018 at 10:34, Radu Nicolau <radu.nico...@intel.com> wrote:
> 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 <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>
> *Cc:* 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
> <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>
> *Cc:* 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> 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
>
>
>
>
>
>
