On Mon, Jul 28, 2014 at 10:56 AM, Raoul Duke <[email protected]> wrote:
> still, even if *you* know the tricks, that doesn't do *me* any good if > i don't, or if i don't understand the distinctions between what you've > got in BitC and what I've used in my work life up to now in all other > languages. > It really *was* an obnoxious thing to say, and I shouldn't have indulged myself. Let me try to be more serious for just a moment. We did some instrumentation back when we built my first production debugger at Bell Labs. This was 1986-88. At that time, 50% of all debugger uses consisted of "cs;q" (callstack; quit). One of the things we did as a result was to have the debugger automatically show the top ten call frames when it was started interactively. People loved that. The point being mainly that I understand why call stacks matter. We also did a debugger command language that was intentionally close to the Bourne shell (Dave Korn finished the first internal version of ksh while we were doing this). Many of the early users actually set their personal shell to "debug", with the result that crashing programs would immediately drop them into the debugger rather than needing to be re-run. Finally, we did the first (so far as I know) incremental symbol table walker, so that you didn't have a huge startup delay to read the symbol table. Logging comes up in two contexts: while developing and in the field. As a developer, I'd much rather be in the habit of running *everything* under a debugger. In that case the logging becomes superfluous and I have the debugging tools right at hand when I need them. Dynamically generated code remains an issue, but that's solvable. But if you are running under a debugger, you don't need help from introspection. For in-the-field capture, you need more than a callstack. You also want a record of randomly selected conditional branch choices so you can see how the program got to where it is. Given a very few of these from different users you can get a very clear picture of how the bug arose without disclosing much (if any) of the user's proprietary state. The main point is that this is something you need to get from the runtime; the program has already faulted, so it is in no position to deliver this. Then we get into stack introspection for security, and I'm going to make a strong statement here: stack introspection is such a wrong-headed approach to security that it is worth getting rid of stack introspection purely to eliminate the wrong and ineffective approaches to security that rely on that feature. > so at the very least i'd suggest that there needs to be some attempt > to pay attention to the practices, however heinous, of Regular Joes > since you seem to be saying sometimes you have to keep that in mind! > and then explain how things can be done that are alternatives or close > enough or whatever, in BitC. > It's a tricky balance. You definitely have to pay attention to what people *need*. You sometimes have to avoid the ways that they currently solve their problems, but if you want acceptance you have to pick your battles. I do agree that this needs a clear solution with illustrating examples. > In any case, if you do need to do it, walking the call stack is a runtime > > function. It can be done as an "arm's length" operation. The problem > isn't > > so much acquiring a dump of the current stack as it is exposing the > stack to > > mutation. > right, and i don't believe i ever stated i wanted to mutate anything, > so i don't understand how it seems to have become contentious for me > to say out loud how i have made a living at programming pragmatically > since it never included raping the stack. I didn't think it was contentious. I'm probably reacting to the "camel's nose in the tent" rather than anything specific about the stack issue. Switching sides, what I'd *really* like is an interactive REPL loop with a full LISP-style debugger available to me. :-) shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
