[rust-dev] autotrace

2013-09-30 Thread Jason E. Aten
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

Re: [rust-dev] autotrace

2013-09-30 Thread Josh Matthews
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

Re: [rust-dev] autotrace

2013-09-30 Thread Jason E. Aten
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.

Re: [rust-dev] autotrace

2013-09-30 Thread Keegan McAllister
surely global_tracking_flag could be persuaded to live in a register, no? Reserving a register will slow down the whole program. I'd expect a serious hit on 32-bit x86, and modest but measurable slowdown elsewhere. It might be worth doing a quick experiment, if there's a way to convince LLVM

Re: [rust-dev] autotrace

2013-09-30 Thread Jason E. Aten
Interesting idea, the self-modifying code. Is that codable in rust currently? On Mon, Sep 30, 2013 at 1:06 PM, Keegan McAllister kmcallis...@mozilla.comwrote: surely global_tracking_flag could be persuaded to live in a register, no? Reserving a register will slow down the whole program.

Re: [rust-dev] autotrace

2013-09-30 Thread Jason E. Aten
I'm wondering if much of this couldn't be prototyped with macros. Is there a way for a macro to refer to the return value of a function? On Mon, Sep 30, 2013 at 1:13 PM, Jason E. Aten j.e.a...@gmail.com wrote: Interesting idea, the self-modifying code. Is that codable in rust currently?

Re: [rust-dev] autotrace

2013-09-30 Thread Alex Crichton
Currently you can't do that with macros, but in theory you could crate a wrapper macro to declare all your functions which works similarly to the externfn! macro. It could debug entry/exit and otherwise just be a wrapper around an internally declared function. On Mon, Sep 30, 2013 at 1:35 PM,

Re: [rust-dev] autotrace

2013-09-30 Thread Keegan McAllister
Is that codable in rust currently? Well, there are two parts to this: the automatic insertion of logging calls, and the runtime feature to enable/disable them. The former would be part of the compiler and can directly emit appropriate LLVM along with table entries to say what should be NOP'd

Re: [rust-dev] autotrace

2013-09-30 Thread Jason E. Aten
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

Re: [rust-dev] autotrace

2013-09-30 Thread Sanghyeon Seo
surely global_tracking_flag could be persuaded to live in a register, no? No. Although this is implemented in GCC, this is unimplemented in LLVM and upstream is not keen on implementing it. See Global Register Variables note at http://nondot.org/sabre/LLVMNotes/ and LLVM bug 16877.