[U-Boot] packed attribute problem

[Scott Wood]

On Thu, 7 Oct 2010 11:59:07 +0200
Detlev Zundel <dzu at denx.de> wrote:

> Hi Scott,
> 
> > So instead of the code breaking in the obvious situation where the
> > unaligned address is assigned to a pointer type that implies alignment,
> > it breaks when sufficient barriers to optimization are added that the
> > compiler can no longer keep track of where the value came from?
> 
> This is getting somewhat theoretical here, but I do not believe that "a
> pointer type implies alignment" in C.

I think this gets down to how such pointers are generated -- if you
stick with well-defined C, the compiler/ABI should be able to avoid
generating an unaligned pointer.

> I may be wrong here, but I cannot
> think of any statement in the standards in this regard - it's only data
> types that imply alignments.

Pointers point to typed data...

>  So if this is true, then for pointers gcc
> will always have to reason from actual values assigned to them.

That's not always possible.  How will GCC reason about this pointer,
where foo is called from a different compilation unit?

int foo(int *ptr)
{
	return *ptr;
}

> 
> > Seems like the right thing is for GCC to warn about the assignment to a
> > plain "u32 *", and allow a warningless assignment to something like
> > "u32 __attribute__((packed)) *".
> 
> Somehow I still feel that gcc should _always_ generate 32-bit accesses
> when I dereference a u32 pointer in code.

C doesn't guarantee this, and it would be broken on certain chips
when unaligned, e.g. old ARM chips that do weird rotaty things rather
than trap when you do an unaligned access.

This is why MMIO accessors should be done with inline assembly rather
than a volatile pointer, although it's usually just a theoretical
concern.

> If such an access traps the machine, then so be it.  Then the code has
> to be changed to reflect this in the source code level which will _make
> programmers ware of it_.

There is something at the source code level triggering this:
__attribute__((packed)).

That said, I don't think a lack of alignment of certain fields within
the struct ought to imply a lack of alignment of the start of the
struct.  There should have been two separate attributes for that, but
changing it now would probably not be a good thing (unless two entirely
new names are introduced).

-Scott