[U-Boot] packed attribute problem

[Scott Wood]

On Thu, 7 Oct 2010 21:31:43 +0200
Wolfgang Denk <wd at denx.de> wrote:

> Dear Scott Wood,
> 
> In message <20101007135257.05a93975 at udp111988uds.am.freescale.net> you wrote:
> >
> > > It is a pretty common method to use a pointer to some struct (for
> > > example, some form of PDU) and make it point to some I/O buffer.
> > 
> > Yes, but at that point we are not talking about well-defined C, but
> > rather implementation-specific behavior.  There's nothing wrong with
> > it, but the C standard is no longer authoritative on what happens in
> > such cases.
> 
> Huch?  Which part of that is not well-defined (or even not
> standard-conforming) C?

Well, how do you obtain the unaligned pointer?

Casting an integer to a pointer?  6.3.2.3: "An integer may be converted
to any pointer type. Except as previously specified, the result is
implementation-defined, might not be properly aligned, and might not
point to an entity of the referenced type."

Casting a pointer to a pointer of a different type?  6.3.2.3: "A pointer
to an object or incomplete type may be converted to a pointer to a
different object or incomplete type. If the resulting pointer is not
correctly aligned for the pointed-to type, the behavior is undefined."

I was expecting to find something stating that it was not well-defined
behavior if you dereference a pointer that points to data of a
different type, but couldn't (maybe I wasn't searching for the right
terms) -- though a similar limitation is present in 6.5.2.3 for unions:
"With one exception, if the value of a member of a union object is used
when the most recent store to the object was to a different member, the
behavior is implementation-defined."

Extensions like __attribute__((packed)) are obviously not
well-defined C.

> > Yes.  And there would also be performance complaints if each of those
> > accesses were to trap and be emulated (even ignoring weird stuff like
> > old ARM).  Thus it's nice to have some sort of pointer or data type
> > annotation to tell the compiler to be careful.
> 
> I also complain about poor performance when instead of a single
> instruction (a 32 bit load) at least 4 (8 bit) instructions need to be
> executed.

So only use the unaligned annotation when there's a significant chance
of it really being unaligned -- and make sure the compiler knows
whether the cost of an unaligned access is significantly worse than the
cost of its workaround.

> > BTW, I see GCC splitting accesses to bitfields in a packed
> > struct into bytes on powerpc, even with -mno-strict-align.
> 
> Indeed. Bitfields have always been evil.

Evil or not, I don't see why GCC feels the need to do this.

-Scott