[lldb-dev] [Bug 20319] New: Crashes on run with Segmentation Fault

2014-07-16 Thread bugzilla-daemon
http://llvm.org/bugs/show_bug.cgi?id=20319 Bug ID: 20319 Summary: Crashes on run with Segmentation Fault Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Pri

[lldb-dev] static fields and consts on a class

2014-07-16 Thread Carlo Kok
I've explored the internal and external apis for LLDB, but I cannot find any way to expose (from LLVM) a static field on a class (like Java: class Test { public static int A = 15; }) or a constant on a class. How do I do this and read it out again with LLDB? -- Carlo Kok RemObjects Softwar

[lldb-dev] Getting the instance/static methods on an objc class

2014-07-16 Thread Carlo Kok
How do I get a list of the methods (and the signatures) if I have the SBType for a given objc type? If that can't be derived from the objc type info, what do I need to do to expose it from the llvm side? -- Carlo Kok RemObjects Software ___ lldb-d

Re: [lldb-dev] unit testing C++ code in LLDB

2014-07-16 Thread jingham
I'm a little leery about this. We don't test at the lldb_private layer because those tests are likely to be fragile and easily broken. For utility classes like NamedPipe I guess I don't so much mind, but I'm not sure its a great idea to do this more generally. Jim > On Jul 16, 2014, at 9:40

Re: [lldb-dev] unit testing C++ code in LLDB

2014-07-16 Thread Todd Fiala
I suspect there are only a handful of cases where I'd like to do this. Frankly I can even do it outside the source base proper, I suppose, but I figured I'd throw the question out here since maybe this is something we care about longer term. I'm not really interested in hitting the app at multipl

Re: [lldb-dev] Getting the instance/static methods on an objc class

2014-07-16 Thread jingham
llvm doesn't include method definitions in the type DIEs for an ObjC class, just the properties and ivars(neither did gcc.) The method table for ObjC is dynamic so I'm not sure it would make sense to do this. lldb currently looks up method invocations one by one when it needs them (mostly in