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
