On Sat, Sep 29, 2012 at 10:12 AM, Spencer Oliver <[email protected]> wrote: > On 29/09/12 07:44, Freddie Chopin wrote: >> >> 1. Reverting the change gets OpenOCD to the state it was in before - >> every algorithm that worked then will work after revert. Every algorithm >> that was broken at that time will still be broken. Quick and easy, not a >> real fix. We just get rid of the regression and not the real problem. >> >> 2. Finding and removing static pointers to working area that the code >> tries to reuse - slow digging through the code, possible side effects? >> >> 3. Converting the code to NEVER store pointers to working area anywhere >> (as there is no point in doing that - right?) - a slow and real fix, >> possible side effects? >> >> If we'd choose fix #1 it wouldn't require much testing as it's just a >> revert. Other fixes would probably need some kind of short RC phase. >> > > A lot depends on how much time people can offer. > I should be able to spend some time on this from tuesday. > > If we feel this cannot wait a week then we need to revert and role out a bug > fix release - what's the general consensus ? >
For a bugfix release, I think it's reasonable to just reinstate the user pointer. The risk of introducing other regressions when fixing all call sites is probably significant, and it would be hard to test all different code affected. The few callers using auto variables could be audited for problems, but any bugs there would have existed pre-0.6.0 as well. The direction bug in the new ftdi driver could also be a candidate for inclusion in a bug fix release. > >> I think you should upload your patch to gerrit or post it to the list >> now (in "unpolished" form)- I'd like to help you with it and I'd see how >> much of "it" is there, this could help us decide on what to do with >> 0.6.0->0.6.1 release. Maybe there will be some more volunteers to help >> with it - who knows? >> > > Andreas patches i guess are here: > http://repo.or.cz/w/openocd/andreasf.git/shortlog/refs/heads/work_alloc > Yes. They need a bit of rebasing work. I could take a stab at it this weekend, perhaps. But there are also other places such as the mips fast data mentioned. Preferably we should solve all problems similarly, so we need to agree on the general method. If we remove all re-use of working areas, there's probably no need to store the pointers outside the functions at all, so if we go that route we should probably take Freddie's option #3. The big question is if some code is very dependent on re-use of working areas (for performance). In that case we could add a proper mechanism to keep, but invalidate, an allocation on target resume etc, instead of the unconditional freeing as today. The drivers would use a validity check instead of checking if it's own pointer is nullified to know when they need to re-upload the algorithm. Allocations would only be freed explicitly. On the other hand, that may still not be safe, since other things than target resume/reset could destroy working area contents (such as the user interactively writing memory with mdw), so we would need to invalidate on those events too => complex and may not be many opportunities left for any performance gains. /Andreas ------------------------------------------------------------------------------ How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
