Non-word-aligned union assignment or read results in data abort

Hugo van der Wijst

I am using the TI ARM compiler v5.0.4, with the TMS570 microcontroller. I've encountered a compiler bug when assigning unions. Attached is a program with different tests.

Assignments to unions are implemented using the STMEA instruction and reading unions using the LDMFD instruction. When the union is not word-aligned, this leads to data abort exceptions. See the example program, test cases 1 and 2.

As a workaround, one can use the memcpy method, though that is optimized to STMEA and LDMFD instructions when passed union pointers or void pointers. To force a call to memcpy, one can cast the source to a uint8_t*. See test case 3.

This is not a problem for structs, as there the assignment seem to always be translated to a memcpy call. See test case 4.

When embedding a union in a struct the generated code behave correctly, as the union is word-aligned in the struct. When packing the struct, memcpy is used to copy the data (also correct). See test case 5.

example.c

Fullscreen

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
#include <stdint.h>
// Test to run
#define TEST 1
struct message {
    uint8_t type;
    uint8_t data[11];
};
enum TYPES {
    TYPE1 = 1,
    TYPE2
};
struct type1 {
    uint32_t data1;
    uint16_t data2;
};
struct type2 {
    uint8_t length;
    uint8_t data[10];
};
union data_type {
    struct type1 t1;
    struct type2 t2;
};
struct message_union {
    uint8_t type;
    union data_type data;
};
struct __attribute__((__packed__)) message_union_packed {
    uint8_t type;
    union data_type data;
};
void main()
{
    union data_type dt;
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

#include <stdint.h>

// Test to run
#define TEST 1

struct message {
    uint8_t type;
    uint8_t data[11];
};

enum TYPES {
    TYPE1 = 1,
    TYPE2
};

struct type1 {
    uint32_t data1;
    uint16_t data2;
};

struct type2 {
    uint8_t length;
    uint8_t data[10];
};

union data_type {
    struct type1 t1;
    struct type2 t2;
};

struct message_union {
    uint8_t type;
    union data_type data;
};

struct __attribute__((__packed__)) message_union_packed {
    uint8_t type;
    union data_type data;
};

void main()
{
    union data_type dt;
    dt.t2.length = 1;
    dt.t2.data[0] = 42;

    struct message msg;
    msg.type = TYPE2;

    union data_type *msg_data = (union data_type *) msg.data;
#if TEST == 1
    *msg_data = dt; //< DATA ABORT! (STMEA)
#elif TEST == 2
    dt = *msg_data; //< DATA ABORT! (LDMFD)
#elif TEST == 3
    memcpy(&dt, (uint8_t*)msg_data, sizeof(union data_type)); //< uses memcpy, no data abort
    memcpy(&dt, msg_data, sizeof(union data_type)); //< uses LDMFD and STMEA, DATA ABORT!
#elif TEST == 4
    struct type2 t2;
    t2 = msg_data->t2; // calls memcpy, no data abort
    struct type2 *msg_type2 = (struct type2 *)msg_data;
    t2 = *msg_type2; // calls memcpy, no data abort
#elif TEST == 5
    struct message_union msg_u;
    msg_u.data = dt;
    struct message_union_packed msg_up;
    msg_up.data = dt;
#endif

    for(;;) ;
}

over 12 years ago

Hugo van der Wijst over 12 years ago

Prodigy 40 points

So, lets add my questions:

Is my assessment that these are compiler bugs correct, or am I missing something?
Are there other workarounds available apart from using memcpy?
What is the expected release time for a fix?

Regards,

Hugo

Hugo van der Wijst over 12 years ago in reply to Hugo van der Wijst

Prodigy 40 points

The problem can be reduced to non-word aligned struct accesses.

I've attached a very small example that triggers the error.

Norman Wong over 12 years ago in reply to Hugo van der Wijst

Guru 26430 points

I'm surprised that Archaeologist or George Mock hasn't chimed in yet. I think what you are seeing is by design and to spec. I think the compiler expects structures to be allocated via declaration. The compiler will ensure that the declared structure is aligned properly. With structure to structure copy, the compiler assumes correct alignment and uses the most efficient aligned copy instructions. It's only when either destination or source is known to unaligned that the compiler will result to a byte by byte copy. Giving a structure the unpacked attribute would tag a structure as unaligned. As part of it's optimization, it looks like the compiler also replaces memcpy calls with inlined aligned copies. What are trying to do? Are you unpacking a packed structure into a unpacked structure?

Archaeologist over 12 years ago in reply to Norman Wong

TI__Guru* 84225 points

Norman Wong said:
I'm surprised that Archaeologist or George Mock hasn't chimed in yet.

We've got to give everyone else a chance to respond once in a while.

Norman is correct, example_simple.c invokes undefined behavior by casting an address that is not properly aligned for type "struct S" into the type pointer to "struct S". This program is not a legal C program. The remedy here is as suggested, use "unpacked".

Hugo van der Wijst over 12 years ago in reply to Norman Wong

Prodigy 40 points

You're right: according to ISO C99 (§6.3.2.3): "A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned for the referenced type, the behavior is undefined."

I was trying to save memory by packing structures containing other structures, and then passing pointers of the inner structures to other methods. I'll align the structures, and see if I can reorder the fields to save space.

I assume this means that you should never pass pointers to objects in a packed structure, as the information that the object is unaligned is lost in the method call.

Thanks for the anser!

Hugo

Code Composer Studio™︎

Code Composer Studio forum

Non-word-aligned union assignment or read results in data abort