On Tue, 2009-12-01 at 11:14 +0100, Øyvind Harboe wrote: > > Again, you have missed the point. This is about users and our releases. > > I cannot make that point more clearly. It is not about developers who > > are willing to use GDB. It's about users who aren't. > > I haven't done the statistics, but are we not seing SEGFAULT's > in development builds mostly?
Mostly. Without built-in stack traces, we may not be getting good reports even from casual developers, as they decide it's too much work to track down a random bug. If the stack trace makes the bug reporting process a little bit easier, right there, it's a win for us.... And this shows how we need to take selection bias when accounting for the present state of affairs. We can't assume that the lack of segfault reports means a lack of segfaults. It could show unwillingness to track down odd crashes that users experience only now and again. Personally, I won't work very hard to reproduce a random crash, but a stack trace would give me an potential fast-path to the means of investigating it immediately. Some bugs require a set of such traces before their cause becomes apparent, and I'm am a little surprised we haven't had more of them with Jim. I sure could have used this feature when working on the 'unknown' command handler. I could have completely skipped using GDB at all, but I had to break down when I hit some trouble with recursion. The new stack facilities offer the ability to add an algorithm that spots endless recursion in Jim by looking for a pattern of N repeating k-frames (where N is fairly big). Or, it could be used to find a high-water mark for our stack usage, and simply warn when it exceeds that by some threshold. That shows how this code could be used to improve our deployed runtime resilience, putting aside symbol lookup. For the relative complexity of its interpreted language, Jim seems to cause us comparatively little grief as far as bug reports go. That's another reason that I see it as daunting to tackle a clean-up; it's likely to only cause regressions. ;) > I'm interested in your solution, but I don't want to see it pushed *soon*. > > Is there a particular urgency to get this resolved *now* or do I > have time? (a week or two). It's not high pressure, and I need to implement no-op versions that can be used by platforms that lack their own implementation. With such facilities in place, others can add support for these (presently) optional APIs at their own leisure. This will make it easy to phase in loadable module support later, which -- of course -- will be a completely optional feature too. --Z _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
