Date: Tue, 3 Sep 2013 15:37:27 +0200 From: Michael Tuexen <tuexen@FreeBSD.org> To: Ian Lepore <ian@FreeBSD.org> Cc: freebsd-arm@FreeBSD.org Subject: Re: A simple question about C... Message-ID: <AC400DAE-B10A-477D-A639-5C19D771CA5A@FreeBSD.org> In-Reply-To: <1378212679.1111.366.camel@revolution.hippie.lan> References: <DA4B80F8-E42F-4230-BD45-929CE92F1098@freebsd.org> <1378212679.1111.366.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 3, 2013, at 2:51 PM, Ian Lepore <ian@FreeBSD.org> wrote:
> On Tue, 2013-09-03 at 14:31 +0200, Michael Tuexen wrote:
>> Dear all,
>>=20
>> I'm trying to get a C program (packetdrill) running FreeBSD r254973
>> on a Raspberry Pi.
>> Since tests are failing, I wrote the little C program:
>>=20
>> #include <stdint.h>
>> #include <stdio.h>
>> #include <string.h>
>>=20
>> int
>> main(void)
>> {
>> uint8_t byte[] =3D {0x00, 0x01, 0x02, 0x03,
>> 0x04, 0x05, 0x06, 0x07,
>> 0x08, 0x09, 0x0a, 0x0b};
>> uint32_t i, n, *p;
>>=20
>> for (i =3D 0; i <=3D 8; i++) {
>> p =3D (uint32_t *)(byte + i);
>> memcpy(&n, byte + i, sizeof(uint32_t));
>> printf("p =3D %p, *p =3D %08x, n =3D %08x.\n", (void =
*)p, *p, n);
>> }
>> return (0);
>> }
>>=20
>> It produces the following output:
>>=20
>> p =3D 0xbfffec48, *p =3D 03020100, n =3D 03020100.
>> p =3D 0xbfffec49, *p =3D 00030201, n =3D 04030201.
>> p =3D 0xbfffec4a, *p =3D 01000302, n =3D 05040302.
>> p =3D 0xbfffec4b, *p =3D 02010003, n =3D 06050403.
>> p =3D 0xbfffec4c, *p =3D 07060504, n =3D 07060504.
>> p =3D 0xbfffec4d, *p =3D 04070605, n =3D 08070605.
>> p =3D 0xbfffec4e, *p =3D 05040706, n =3D 09080706.
>> p =3D 0xbfffec4f, *p =3D 06050407, n =3D 0a090807.
>> p =3D 0xbfffec50, *p =3D 0b0a0908, n =3D 0b0a0908.
>>=20
>> So everything is fine when reading the 4 byte long uint32_t on a =
4-byte aligned
>> address. Results are strange (at least for me), when the address is =
not 4-byte
>> aligned. There is no difference between clang and gcc. Can I only =
dereference
>> properly aligned pointers? Is the above expected or is it a bug in =
the compiler?
>>=20
>> Best regards
>> Michael
>=20
> Yes, you can only safely dereference pointers aligned to the size of =
the
> dereference (2, 4, 8 bytes). On some ARM platforms a misaligned
> reference leads to alignment fault, on others the data is rotated in
> some predefined way, and on some it's just "undefined behavior."
>=20
> There are functions in endian.h to help with the alignment, in
> particular the leNNdec() and leNNenc() functions are designed to be
> alignment-agnostic.
OK. Thanks for the information. This means the packetdrill source code
has to be patched to work correctly on ARM... Need to find all the =
places
where they access stuff in a non-aligned way.
Best regards
Michael
>=20
> -- Ian
>=20
>=20
>=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AC400DAE-B10A-477D-A639-5C19D771CA5A>