[lldb-dev] DWARF v5 unit headers

2017-02-27 Thread Robinson, Paul via lldb-dev
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!

2017-02-27 Thread George Burgess IV via lldb-dev
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

2017-02-27 Thread Zachary Turner via lldb-dev
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 Kok  wrote:

> 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

2017-02-27 Thread Carlo Kok via lldb-dev


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

2017-02-27 Thread Carlo Kok via lldb-dev

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