[lldb-dev] DWARF v5 unit headers
I'm planning to commit a patch (http://reviews.llvm.org/D30206) which will cause Clang/LLVM to emit correct unit headers if you ask for version 5. I've run the lldb tests and I *think* I pointed to my modified Clang correctly (cmake with -DLLDB_TEST_COMPILER=/my/clang) and AFAICT it does not introduce new problems. I saw 3 Failure and 12 Error with or without the patch. (One Expected Failure seems to have become an Unexpected Success. Haven't tried to decipher logs to figure out which one yet.) If anybody can predict a problem with my patch, please let me know by noon Pacific time (2000 GMT) tomorrow (28th). We're going to be doing more work implementing various bits of DWARF v5 in the coming months. If anybody thinks they can predict that there are particular bits that would be especially problematic for LLDB, it would be useful to know up front which bits those are. Thanks --paulr ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] March LLVM bay-area social is this Thursday!
We'll be at Tied House as usual, starting on Thursday the 2nd at 7pm! If you can, help us plan and RSVP here: http://meetu.ps/36h805 See everyone there! George ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] logic reversal in StackFrame::Disassemble in r287189
Thanks for the heads up, it does indeed look like an issue. Wonder why it was only just now caught. I'll submit a fix shortly. On Mon, Feb 27, 2017 at 4:24 AM Carlo Kokwrote: > I think something went wrong in r287189: > > > https://github.com/llvm-mirror/lldb/commit/dfd7c7c89c00bbffcb130cf51cd33058ecb5dfcd#diff-3adb8d2b6f1642f0ae63c3cd9326d6e4L221 > > First it checked if the disassembly was empty, if not it filled it, now > it returns null if it's empty (which it will always be initially) > > -- > Carlo Kok > RemObjects Software > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Too many ModuleSP references
On 2017-02-22 18:50, Greg Clayton via lldb-dev wrote: On Feb 21, 2017, at 5:08 PM, Jim Ingham> wrote: On Feb 21, 2017, at 4:49 PM, Jim Ingham via lldb-dev > wrote: On Feb 21, 2017, at 4:24 PM, Greg Clayton via lldb-dev > wrote: - StepOverBreakpointTestCase: Have the test not store the breakpoints in the test case object. Basically, declare that this is not a bug, and it's the users responsibility to clean up necessary objects. It would be nice to avoid this. I don't agree with this. I think trying to force folks using the API from Python to manually clear all stored objects would be really obnoxious. If anything, we should figure out how to make this accidental failure into an intended failure so we can make sure we don't end up requiring this kind of micro-management. It's possible you meant "it would be nice to avoid it's being the user's responsibility to clean up necessary objects", in which case sorry for mis-reading but happy we agree... Yep, that is what I meant. No one should have to worry about cleansing any variables. It should just work. So we need to pick the lldb::SB objects that have strong reference very carefully. I think the same goes for SBValue, whenever I've looked at 'locals' the executable gets locked until my SBValue refs get gcd. -- Carlo Kok RemObjects Software ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] logic reversal in StackFrame::Disassemble in r287189
I think something went wrong in r287189: https://github.com/llvm-mirror/lldb/commit/dfd7c7c89c00bbffcb130cf51cd33058ecb5dfcd#diff-3adb8d2b6f1642f0ae63c3cd9326d6e4L221 First it checked if the disassembly was empty, if not it filled it, now it returns null if it's empty (which it will always be initially) -- Carlo Kok RemObjects Software ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev