On Dec 2, 2008, at 8:35 PM, Duane Ellis wrote:
Hiroshi san,What was the original complaint? If I understand correctly, the problemwas this: ========== cmd_que_allocate() - returns an un-aligned pointer. ==========Is that correct? If so - the cause, and solution is utterly simple, andis as follows: The solution is to *ROUND*UP* all requests to an alignment size.
Or more clearly, adding padding. It will make more sense in 6 months that we pad to ensure alignment rather than round up the allocation size.
For example:If the request is for 13 bytes, the request should be rounded to 16 bytesThis should be done at the start/top of the allocation routine. The cause of the alignment error is an earlier *ODD* size allocation. The memory request *NEXT* will be mis-aligned.Walk through the code - request first 20 bytes, then 5 bytes, then 20 bytes.By simply at the top of "cmd_que_allocate()" - rounding up the allocation size.. the problem is solved. For *ARM* - alignment is 4byte - this one line fix should be ok.
The alignment issue is on the host. The correct behavior would be to imitate malloc(), but since that is nearly impossible to discover, we should settle for doing word alignment. That handles the everything but vector and floating point types.
size = (size + 3) & (~3);Perhaps - with newer platforms (ie: The 64bit - AMD) we should as policyin the code - align to 16bytes? Please try the above and let me know what you find.
That was what the initial patch did. It works fine, but is confusing if you don't understand the issue. Thus, not only is the actual fix necessary, but a nice big comment describing the problem is appropriate as well. I also advocate doing the alignment as part of adjusting the page's used member to make it clear that we aren't resizing the allocation, but padding for alignment. In practice, it is the same thing, but it makes the problem and the solution easier to follow.
Attached is the proposed patch.
openocd-jtag-cmd-alloc-alignment.patch
Description: Binary data
-Duane. _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
-- Rick Altherr [EMAIL PROTECTED]"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
