Hello,

while working on a test case for

https://devel.rtems.org/ticket/3767

I tried to find the right test suite for it. At first I thought that this is a unit test (testsuites/unit/compiler/tc-misaligned-builtin-memcpy.c). However, I now think that we should have a requirement for this function. The test case is more or less clear:

T_TEST_CASE(MisalignedBuiltinMemcpy)
{
        double a;
        double b;
        char buf[2 * sizeof(double)];
        void *p;

        p = &buf[0];
        p = (void *)((uintptr_t)p | 1);
        RTEMS_OBFUSCATE_VARIABLE(p);
        a = 123e4;
        RTEMS_OBFUSCATE_VARIABLE(a);
        a *= a;
        memcpy(p, &a, sizeof(a));
        RTEMS_OBFUSCATE_VARIABLE(p);
        memcpy(&b, p, sizeof(b));
        T_eq(a, b, "%f == %f", a, b);
}

It is obvious that such a memcpy() operation should work. In general, we assume in RTEMS that the compiler does the right job. However, on some architectures we have to select the right compiler options and this is clearly under full control of the RTEMS BSP. I think we should add something like this to the RTEMS requirements:

A call of memcpy() in C from a pointer to a double value to a misaligned destination buffer shall store the double value in the destination buffer.

The formulation is quite specific, but I was not able to formulate it more generic and keep it testable. We have to keep in mind here that we are not interested in the memcpy() C library function, but rather the compiler optimized code for the memcpy() builtin function.

An architecture-specific requirement could be:

The alignment exception shall terminate the system with a fatal error.

If we use the wrong compiler options we may not fulfil both requirements on some platforms.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Reply via email to