Hi Josh, I'm told that rustc itself is a prime example. People on #rust were complaining about how opaque it is, and telling me printfs were the only recourse. Are you saying you *are* able to step through rustc?
I filed a ticket for the stuff that was frustrating me--stepping through the msgpack bindings; full repro steps here: https://github.com/mozilla/rust/issues/9641 Jason On Mon, Sep 30, 2013 at 2:53 PM, Josh Matthews <[email protected]>wrote: > That's very curious, because we have tests exercising all of the > functionality like local variables that show that it should be working. > Stepping could definitely be jumpy, but in general I've found it to be > quite usable. Try building without -Z debug-info, since -Z extra-debug-info > implies it. I'd also be interested in seeing the code that demonstrates > this problem for you. > > Cheers, > Josh > > > On 30 September 2013 15:18, Jason E. Aten <[email protected]> wrote: > >> Hi Josh, >> >> Could you be more specific about what you would like me to try? When I >> iniquire on #rust I'm told that debug-info is still in bad shape. >> >> Specifically: I do rustc -Z debug-info -Z extra-debug-info -Z no-opt, and >> I consistently get no local variables showing up in gdb on any stack frame. >> The frame pointer jumps to random places in the source code when stepping. >> >> And moreover, --autotrace would so much more useful in that it would >> also allow monitoring of an in-production system without stopping it or >> re-deploying as a debug-build. >> >> Jason >> >> On Mon, Sep 30, 2013 at 12:05 PM, Josh Matthews <[email protected]>wrote: >> >>> Please note that Michael Woerister's work this summer on debug symbols >>> has been wildly successful, and it's worth giving it another shot before >>> looking into further compiler hacking: >>> http://michaelwoerister.github.io/2013/09/27/what-you-call-the-present.html >>> >>> Cheers, >>> Josh >>> >>> >>> On 30 September 2013 14:00, Jason E. Aten <[email protected]> wrote: >>> >>>> I was very frustrated by the lack of debug-info at the gdb prompt >>>> during rust coding recently. I note too that people on #rust complain about >>>> the lack of visibility into debugging rustc itself. >>>> >>>> I think there is a lightweight, quick to implement, solution to these >>>> problems. >>>> >>>> I have in mind a simple facility provided by a compiler flag that >>>> injects (logging-controlled) printf or tracing-log statement at the top and >>>> bottom of every function. Something like: >>>> >>>> // example: >>>> fn fun1(a:int, b:str, c:HashMap<~str, int>) -> HashMap<~str,int> { >>>> c.insert(a,b) >>>> } >>>> >>>> // would effectively become, with rustc --autotrace enabled: >>>> >>>> fn fun1(a:int, b:str, c:HashMap<~str, int>) { >>>> // intro >>>> if (global_tracking_flag) { >>>> stack_depth = stack_depth + 1; >>>> trace!("%s call fun1(%?, %?, %?)", >>>> indent_spaces_according_to_stack_depth(), a, b, c); >>>> } >>>> >>>> c.insert(a,b); >>>> >>>> // outro : would have to be like a destructor, that is called on >>>> every return path... >>>> if (global_tracking_flag) { >>>> trace!("%s return from fun1 -> %?", >>>> indent_spaces_according_to_stack_depth(), c); >>>> stack_depth = stack_depth - 1; >>>> } >>>> } >>>> >>>> >>>> Although not without cost, the --autotrace facility could even be >>>> highly useful for runtime monitoring (and therefore better/faster/cheaper >>>> than comprehensive debug-info). The idea being that it would be cheap >>>> enough (surely global_tracking_flag could be persuaded to live in a >>>> register, no?) that it could be left compiled into most non-inlined >>>> function, and activated at runtime without bringing a production system >>>> down. >>>> >>>> Related experience.... Justin Sheehy at Basho talks about how Erlang's >>>> runtime monitoring facilities were under-appreciated when they started. >>>> >>>> "Many other features that we didn’t understand the full importance of >>>> at the time (such as the ability to inspect and modify a live system at >>>> run-time with almost no planning or cost) have also helped us greatly in >>>> making systems that our users and customers trust with their most critical >>>> data." http://basho.com/erlang-at-basho-five-years-later/ >>>> >>>> Thoughts? Is --autotrace a viable idea at all? >>>> >>>> Jason >>>> >>>> >>>> _______________________________________________ >>>> Rust-dev mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/rust-dev >>>> >>>> >>> >> >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
