Re: [lldb-dev] LLDB tests

Steve, since you asked about failures, here are some public bots you can look at to get a general sense of how we are doing: * http://lab.llvm.org:8011/builders [various platforms] * http://lab.llvm.org:8080/green/view/LLDB/job/lldb_build_test/ [OS X] *

Re: [lldb-dev] Execution contexts in the OptionValue subsystem?

, Sean Callanan via lldb-dev <lldb-dev@lists.llvm.org> wrote: There's a function in OptionValueProperties (http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Interpreter/OptionValueProperties.cpp?view=markup line 234): const Property *OptionValueProperties::GetPropertyAtIndex( const Exec

[lldb-dev] Execution contexts in the OptionValue subsystem?

There's a function in OptionValueProperties (http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Interpreter/OptionValueProperties.cpp?view=markup line 234): const Property *OptionValueProperties::GetPropertyAtIndex( const ExecutionContext *exe_ctx, bool will_modify, uint32_t idx) const

Re: [lldb-dev] Connecting to lldb-rpc-server

Once you have Python commands, could you make them into a simple RPC service and set up a new socket connection to your program from the LLDB side, all implemented in Python? Sean > On Oct 7, 2016, at 12:29 PM, Jim Ingham via lldb-dev > wrote: > > Enrico is right.

Re: [lldb-dev] RFC: Break/Watchpoint refactor

macro states the intent explicitly, rather than having to deduce >> it from details scattered through the class definition. >> >> Jim >> >>> On Sep 27, 2016, at 3:13 PM, Sean Callanan via lldb-dev >>> <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists

Re: [lldb-dev] RFC: Break/Watchpoint refactor

Doing it everywhere would be a public service IMO. I don't like macros either. Sean > On Sep 27, 2016, at 3:07 PM, Zachary Turner via lldb-dev > wrote: > > FWIW LLVM removed all it's disallow copy / assign macros in favor of > explicitly writing it. I agree it's

Re: [lldb-dev] LLDB Evolution - Final Form

My 2¢: > assert(p); > int x = *p; > … > assert(ptr); > int x = strlen(ptr); Both of these should either check for null, be in a situation where p is obviously good (e.g., p is data() from a stack-allocated std::vector), or use references. The assertion to my mind is like an admission "I'm

Re: [lldb-dev] LLDB Evolution

In fact, the lldbinline tests could be completely broken by clang-formatting them. They treat each //% line as a separate command to execute. If clang-format broke those lines, lldbinline tests would stop working. Sean > On Aug 11, 2016, at 9:57 AM, Chris Lattner via lldb-dev >

Re: [lldb-dev] r260768 (Removed many JIT workarounds from IRForTarget) broke expression parser with function on Hexagon

t 2:36 PM, Sean Callanan via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > I think I understand what’s going on. The IR interpreter does this > [IRInterpreter.cpp:1573]: > – > // Find the address of the callee function >

Re: [lldb-dev] r260768 (Removed many JIT workarounds from IRForTarget) broke expression parser with function on Hexagon

I think I understand what’s going on. The IR interpreter does this [IRInterpreter.cpp:1573]: – // Find the address of the callee function lldb_private::Scalar I; const llvm::Value *val = call_inst->getCalledValue(); if

Re: [lldb-dev] r260768 (Removed many JIT workarounds from IRForTarget) broke expression parser with function on Hexagon

At that point, I’d set a watchpoint and see what is setting it. I would expect that %call = call i32 @factorial(i32 5) would put a normal value in call, which would then be the value stored by the store instruction store i32 %call, i32* @"_ZZ12$__lldb_exprPvE19$__lldb_expr_result", align

Re: [lldb-dev] Details on rdar://18684408?

I apologize for this confusion. I recently fixed these as a side effect of some major changes in IRForTarget.cpp. These should be fixed on pretty much all platforms, and the expectedFailure can be removed. If they’re passing on Linux too, let’s remove the expectedFailure. Sean > On Feb 18,

[lldb-dev] LLDB does some deep recursion into external modules to resolve name lookups

I’ve been investing the “po performance bug” ( po when debugging Xcode is extremely slow) in recent Xcode, and I discovered this problem. We are looking at pch files that are generated on Xcode’s behalf and it looks like we’re recursing through their dependencies when we don’t find something,

Re: [lldb-dev] clang-format now supports return type on separate line

Wow, that’s a super handy feature and probably goes a long way toward alleviating concerns about tables. I have to say, I always feel good vibes about a source base when they have lint directives in comments. Shows they run lint as a matter of course. Sean > On Jan 22, 2016, at 12:29 PM,

Re: [lldb-dev] clang-format now supports return type on separate line

I tend to agree with Zachary on the overall principle – and I would be willing to clang-format functions when I modify them. I’m concerned about a specific class of functions, though. Let’s say I have a function that has had lots of activity (I’m thinking of, for example, ParseType off in the

Re: [lldb-dev] bindings as service idea

I don’t think so, this was just an embedded link to your hard drive: file:///C:/tools/swigwin-3.0.7/Doc/Manual/Python.html#Python_builtin_types Sean > On Nov 19, 2015, at 10:51 AM, Zachary Turner via lldb-dev > wrote: > > > > On Thu, Nov 19, 2015 at 10:50 AM