On 2006-09-12, Neil Wyper <[email protected]> wrote:
>>> My program is broken because mspgcc 3.2.3 is generating
>>> unaligned word accesses. I'm calling memset() and memcpy()
>>> fill in the fields in a packed struct. Since I've requested a
>>> 2-byte copy/set mspgcc is optimizing some of those memset()
>>> and memcpy() calls into mov.w instructions, but the
>>> destination address isn't word aligned, so the generated code
>>> is not correct.
>>
>> It appears to be doing the same thing for 4-byte memcpy()
>> operations. :(
>
> This was noted on the list a year ago:
> http://www.nabble.com/memcpy-assumes-16-bit-alignment--t712619.html
That sounds like the same problem. Especially the unsupported
relocation (which happens if you do an assignment to a
misaligned packed struct field).
[Since the compiler knows the structure is packed and the
destination field is misaligned, it should be able to generate
correct code for the assignemnt, but that's a slightly
different problem.]
What I don't understand is that thread's discussion of the
memcpy() code that's in libc. If it's the same problem, then
it's got nothing to do with code in libc.
> msp430-libc/src/string/bcopy.c hasn't changed since then, so
> the bug is still present.
If that previous bug was in libc code, then this is a different
problem. The bug I'm reporting isn't in libc, it's in the
compiler. If you note the generated code in my original
posted, memcpy() is never called.
The compiler generates a mov.w instruction with an odd
destination address. The compiler has generated an instruction
that isn't allowed by the architecture.
Besides the fact that memcpy() isn't being called in the
failure cases I've described, I've analyzed bcopy.c, and I
don't see anything wrong with it. Unless somebody can point out
exactly where the bug is, I'm going to have to say the posters
in the original thread were wrong about there being a bug in
libc's memcpy().
If you don't trust my judgment (no reason you should
particularly), there's also the fact that the bcopy.c in
msp430-libc is the standard BSD library code that's been beaten
to death for a over dozen years on as many acrictures (many of
which have memory alignment requirements like the MPS430). I
just checked the FreeBSD CVS repository, and that code is still
in use in FreeBSD systems today.
There's no bug in the libc memcpy().
> The thread from last year did include a possible replacement
> memcpy() from Daniel Néri.
There's no bug in memcpy(). The compiler isn't even calling
memcpy() in the code that's failing.
I'm _guessing_ that by providing his own memcpy() function, the
user is preventing the compiler from using the (broken)
intrinsic code that assumes 16-bit alignment for operations
greater than 1 byte long.
--
Grant Edwards grante Yow! Will it improve my
at CASH FLOW?
visi.com
