Hi everyone, I think the ideal debugger needs to do a combination of both, instrumentation and DWARF-style debugging. The trade offs are very different (instrumentation gives you easy access to variables, AST-level stepping at the cost of performance of the instrumented code, while the other gives you the ability to see stack frames, set break points and yes, nicely step through other languages as well). When I set out to do this, I decided to start with the second part, because I believe that once I put the foundations in place for that, the rest will be relatively easy to do.
The way I see a traditional debugger and instrumentation interacting is that a traditional debugger is the primary, so you can run your program, interrupt it etc. Then, at very well defined locations, the debugger can request that the target replace a function by an instrumented version. Initially I'm gonna target automatic deoptimization to a lower debug level, but I'm planning to make it generically available, so people can write their own instrumentations and plug them in dynamically. My real goal is for me to create a platform and have other people write packages that make use of it to provide cool functionality (e.g. integrate with rr, or KLEE or any of the numerous published debugging techniques that never actually make it into production because the low-level implementation details are too tedious). I'd also be happy to see where one can take instrumentation based debugging (and I'll probably be able to reuse it once my debugger is at that stage), but I'm hoping to create something that will be the go-to tool for everybody (including me, and I'd like to think I have some strong requirements), not something that I'd have to set aside the minute something goes wrong in favor of a "proper" debugger that is less nice to use. Keno On Tue, Jun 2, 2015 at 1:26 PM, Tim Holy <tim.h...@gmail.com> wrote: > I don't think Debug was mentioned explicitly in your original post, but I > see > you did say "navigate stack frames" and certainly Debug can't do that. > > How exactly do you think that can be accomplished, without doing something > along the lines of what Keno is doing? I don't have the impression that > seamless julia/c is his primary focus; I think it's more that it will be a > nice side effect of just getting stack-frame-navigating debugging working. > > I think the reason Debug.jl hasn't gotten a lot of attention is because > it's > basically "done," meaning that it's not obvious (to me at least) that an > instrumenting debugger can get much better. If you have some concrete > suggestions, they could be very interesting. > > Best, > --Tim > > On Tuesday, June 02, 2015 09:04:58 AM Michael Turok wrote: > > Yes - but it hasn't gotten much attention over the last two years (and > > sorry, I thought I had mentioned Debug.jl in my initial post). > > > > https://github.com/toivoh/Debug.jl/graphs/code-frequency > > > > Feels like there could be a lot of work there that would be tremendously > > helpful, but not sure if people are focused on it (and instead attention > is > > on being able to seamlessly navigate from julia -> c). > > > > Is anyone working on extending the functionality there, or is it viewed > as > > a developmental dead end? > > > > Michael > > > > On Tuesday, June 2, 2015 at 11:31:04 AM UTC-4, Tim Holy wrote: > > > https://github.com/toivoh/Debug.jl > > > < > https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Ftoivoh%2FDebug.jl > > > &sa=D&sntz=1&usg=AFQjCNFVItS_nt9vtR2lzYEoYZu8ZhxJwA> > > > > > > --Tim > > > > > > On Tuesday, June 02, 2015 08:21:51 AM Michael Turok wrote: > > > > Right, but I'm interested in an debugger that would work without a > > > > > > custom > > > > > > > compilation of LLVM, and would work with a stock release of julia > 0.3*. > > > > > > > > On Tuesday, June 2, 2015 at 11:11:09 AM UTC-4, Isaiah wrote: > > > > > https://groups.google.com/d/msg/julia-dev/gcZ5dZJni5o/VYaLkCd756cJ > > > > > > > > > > On Tue, Jun 2, 2015 at 11:07 AM, Michael Turok < > michae...@gmail.com > > > > > > > > > > <javascript:>> wrote: > > > > >> Is there anyone currently focusing on building an AST-level > debugger > > > > > > that > > > > > > > >> can navigate stack frames and not require modifying code to insert > > > > >> instrumentation stubs, etc? > > > > >> > > > > >> While the LLVM JIT debugger referenced in the below thread from > > > > > > December > > > > > > > >> 2013 is interesting, seems like there might be more low-lying > fruit > > > > > > out > > > > > > > >> there..... > > > > > > > https://groups.google.com/forum/#!searchin/julia-users/debugger/julia-use > > > > > > > >> rs/zEqWxn7HDVo/ZTRZh4ziR9kJ > >
