Sure, I'm happy to provide some feedback.
You might say that the real problem is the arm gcc compiler.
For whatever reason, it really likes to align things on 4 byte boundaries,
and pad structures to 4 byte boundaries, even where most other compilers don't.
(Such as the char arrays in the structures in question).
Why is it this way? I can't say (perhaps another arm compiler did it this way).
I know I don't like it because of the problems
it causes with various apps on arm. But the C spec does not place any
requirements on field alignment and structure padding, so we have to accept
that it is OK.
By rights, the use of C structures to represent physical storage should
be avoided because of exactly this problem.
I see the simplest solution is to use the one mechanism this compiler
provides to force structure alignment/packing. The alternative of moving
to a non-structure approach would surely require huge code changes.
FWIW, yes, various other apps have problems too, especially those which
represent network protocols as C structures. The __attribute__(packed)
approach seems to be the preferred approach for these apps.
Regards,
Steve
Joerg Schilling wrote:
Steve McIntyre <[EMAIL PROTECTED]> wrote:
But I would prefer to use standard C constructs:
#pragma pack(1)
Unfortunately, #pragma pack(1) doesn't fix the problem - I've just
tested it on an arm machine here. __attribute__(packed) _does_ fix the
problem. See http://lists.debian.org/debian-gcc/2001/04/msg00102.html
for more details...
I was in hope to get more feedback from the OP.
If the arm platform _really_ has problems in this area, there must be many more
problems. If we do not address the other problems, it makes no sense to do
anything.
I have no access to a arm system, so I cannot test myself.
Jörg
