W dniu 2012-09-29 10:53, Andreas Fritiofson pisze: > 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.
That's a good point for reverting the commit temporarily for 0.6.1. I'm convinced, as we cannot test all affected flash types and instead of fixing one regression we may introduce 3 new ones (; > The direction bug in the new ftdi driver could also be a candidate for > inclusion in a bug fix release. You mean this one? http://openocd.zylin.com/#/c/849/ ? > 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. If we have time (because regression was "fixed" with a revert), then I'm also for #3 - removing all static pointers to working area. > 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. Is there any code that fits such characteristics? I just cannot see anyway it would be possible to gain any performance by having the working area available past resets and resumes - when you do anything that requires working area and should be fast (flashing) you do it in one go without any resumes or resets in between... Thus I think that removal of such static pointers is a good solution. Anyway - "allocation" of working area is fast (everything is done inside OpenOCD - right?), what is slow is uploading/downloading anything there and I just cannot see how one would expect the contents of the working area to be intact after target is resumed or reset... 4\/3!! ------------------------------------------------------------------------------ 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
