- User Since
- Mar 2 2013, 8:12 AM (324 w, 1 d)
Fri, May 17
Nice! FYI, we have a bot that runs the LLDB dotests against DWARF5 (the last stage http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-matrix/) to track the progress.
Thu, May 16
LGTM with three nitpicks inside.
My understanding is that we deliberately don't terminate stack-based variable locations during frame destruction, because the debugger should understand that those become invalid as the frame is destroyed.
Thanks! One bonus cleanup inline :-)
Added test for raw pointer values.
Address review feedback.
Wed, May 15
More tweaks from Jonas & me.
Add more context to the diff.
I think I addressed most/all of the outstanding bugs.
Thanks a lot, this is going to be a far less error-prone API!
Seems reasonable, nitpicks inside.
Tue, May 14
Do you think the fact that sphinx doesn't update the css will be a problem on lldb.llvm.org with the way the script is run? (ninja clean does not delete the html directory either).
Make Doxygen links in sidebar work.
Alright, thanks for taking the time to walk me through the thought process!
Mon, May 13
I think we're getting there!
Thu, May 9
Wed, May 8
Tue, May 7
A slightly more elegant solution might be to inject a #line directive that changes to a different source file for the code that the user entered. I've been long wanting to make expr -g more palatable to end users by hiding the LLDB-injected code in a separate source file by default. If that turns out to be too much work, feel free to land this version.
Mon, May 6
Fri, May 3
Thu, May 2
Thanks you! There was indeed a bug that prevented us from recognizing the correct runtime for the C++ this pointer.
Tue, Apr 30
Mon, Apr 29
There's no hard and fast rules about this, but usually, tiny adjustments to fix issues found by bots can be landed without requiring a separate review.