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
