Hi,
On Fri, 2018-04-27 at 10:04 +0000, Sergio Gonzalez Monroy wrote:
> 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.
According to the GCC documentation (https://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/T
ype-Attributes.html): id="-x-evo-selection-start-marker">"Note that the
effectiveness of aligned attributes may be limited by inherent limitations in
your linker. On many systems, the linker is only able to arrange for variables
to be aligned up to a certain maximum alignment. (For some linkers, the maximum
supported alignment may be very very small.) If your linker is only able to
align variables up to a maximum of 8 byte alignment, then specifying aligned(16)
in an __attribute__ will still only provide you with 8 byte alignment. See your
linker documentation for further information."
Having said that, it is always possible to compile the code (temporarily) with
"-fsanitize=undefined" which would show up all the misaligned accesses which
could cause run-time errors.
>
> Below is the link with some code to play around:
> https://godbolt.org/g/7RDBQG
>
> Regards,
> Sergio
>
>
>
> From: Radu Nicolau
>
> Sent: Friday 27 April 2018 10:34
>
> To: Dave Barach (dbarach);
> Florin Coras
>
> Cc: 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.lists@gmail.c
> om>
>
> 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]
> 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
> >
> >
>
>
>
>
>
>
>
>
>
>
>
>
--
Marco V
SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
