> Looks plausible to me, though I think that LOG_WARNING on the fallback > should be less severe -- maybe LOG_DEBUG. The logic seems to be "try > fastdata if possible, else do the other way" ... so users will have no > control over what it uses, and a WARNING won't help. A single warning > at startup -- "you didn't provide a work area, so writes will be slow" > might do; but ISTR the ARM code doesn't particularly warn about such > stuff for now either. >
changed to a LOG_DEBUG msg. > Also you might merge a cleanup patch to make sure pracc.c (and any > others which need the fix) don't have all that needless end-of-line > whitespace. > > Similarly in pracc.c you're doing runtime init of an array of opcodes, > THEN checking if source->size (work area done without the work area > utils?) is cooperating ... the ARM stuff has all those opcode arrays > "static const" and copies them into a scratch buffer before tweaking > (e.g. byteswapping). > it is using the working area utils, but probably needs a cleanup. > Those large static on-stack arrays will cause trouble on "deeply" > embedded boxes (Zylin). And you could easily check the size before > initializing them ... :) > to be honest there is a lot of wip for ths mips stuff :) I will commit as is and hope to spend some more time in the coming days. Cheers Spen _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
