Re: [lldb-dev] bindings as service idea

[Sean Callanan via lldb-dev]

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 Zachary Turner  > wrote:
> Well some of the bugfixes are actually worth mentioning, because we actually 
> have bugs on the C++ side that we can't fix because then SWIG won't be able 
> to process the header files.  For example, if SWIG sees this in a header 
> file, it errors out and can't even proceed.
> 
> enum Foo : unsigned {
> Bar = 0x
> };
> 
> So instead we have to write this:
> 
> enum Foo {
> Bar = 0x
> };
> 
> According to the standard this produces an unsigned enum, but MSVC is 
> non-comformant here, and we get a signed enum.  So we have hundreds of 
> warnings disabled as a result of this, and it's a legitimate bug on the C++ 
> side that we would like to fix, irrespective of SWIG.
> 
> Feature-wise, here's a potentially incomplete list:
> 
> * Typemaps can re-use other typemaps, similar to how functions can call other 
> functions
> * A new -debug-tmsearch command line option which helps debugging typemap 
> problems.  For example, when you're looking at some generated code and trying 
> to figure out which typemap generated it.  I know I've had to do this many 
> times during the Python 3 conversion, and this would have helped.
> * Template classes are supported.  We probably don't care about this, but 
> it's an interesting thought.
> * -builtin option supports generating higher performance wrapping code.  Read 
> the SWIG documentation about -builtin <>
> Grr, do embedded links not work on the mailing list or something?
> 
> http://www.swig.org/Doc3.0/Python.html#Python_builtin_types 
> 
>  
> 
> JavaScript support has been mentioned as someone someone needs on more than 
> one occasion.  The name of the person interested escapes me, but this wasn't 
> added until SWIG 3.x.  Other languages like Go and Lua aren't in 1.x of SWIG 
> either, I don't believe.
> 
> I'll try to think of some more.
> 
> 
> On Thu, Nov 19, 2015 at 10:17 AM Todd Fiala  > wrote:
> I'm out next week, but I can help if needed after that.
> 
> Related to all this, you have mentioned a few times that there are newer swig 
> features you want to use.
> 
> Can you enumerate the features not present in 1.x but present in 3.x that you 
> want to take advantage of, and what benefits they will bring us?  (I'm not 
> referring to bug fixes in bindings, but actual features that bring something 
> new that we didn't have before).
> 
> Thanks!
> 
> -Todd
> 
> On Thu, Nov 19, 2015 at 10:14 AM, Zachary Turner  > wrote:
> I wasn't planning on working on this immediately, but given the outcome of 
> the recent static bindings work, I can re-prioritize.  I don't know how long 
> it will take, because honestly writing this kind of thing in Python is new to 
> me.. to make an understatement.  But I'll get it done.  Give me until mid 
> next week and I'll post an update.
> 
> On Thu, Nov 19, 2015 at 10:12 AM Todd Fiala  > wrote:
> On Thu, Nov 19, 2015 at 9:44 AM, Zachary Turner  > wrote:
> Just to re-iterate, if we use the bindings as a service, then I envision 
> checking the bindings in.  This addresses a lot of the potential pitfalls you 
> point out, such as the "oops, you can't hit the network, no build for you" 
> and the issue of production build flows not wanting to hit a third party 
> server, etc.  
> 
> So if we do that, then I don't think falling back to local generation will be 
> an issue (or important) in practice.  i.e. it won't matter if you can't hit 
> the network.  The reason I say this is that if you can't hit the network you 
> can't check in code either.  So, sure, there might be a short window where 
> you can't do a local build , but that would only affect you if you were 
> actively modifying a swig interface file AND you were actively without a 
> network connection.  The service claims 99.95% uptime, and it's safe to say 
> we are looking at significantly less than 100% usage of the server (given 
> checked in bindings), so I think we're looking at once a year -- if that -- 
> that anyone anywhere has an issue with being able to access the service.
> 
> 
> That seems fine.
>  
> And, as you said, the option can be provided to change the host that the 
> service runs on, so someone could run one internally.
> 
> But do note, that if the goal here is to get the SWIG version bumped in the 
> upstream, then we will probably take advantage of some of these new SWIG 
> features, which may not work in earlier versions of SWIG.  So you should 
> consider how useful it will be to be able to run this server internally, 
> because if you 

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

[Sean Callanan via lldb-dev]

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 DWARF parser).  
Unfortunately, such functions tend to be the ones that benefit most from 
clang-format.

In such a function, there’s a lot of useful history available via svn blame 
that helps when fixing bugs.  My concern is that if someone clang-formats this 
function after applying the kth fix, suddenly I've lost convenient access to 
that history.  It’s only available with a fair amount of pain, and this pain 
increases as more fixes are applied because now I need to interleave the info 
before and after reformatting.

Would it be reasonable to mark such functions as “Don’t clang-format”?  That 
could be also interpreted as a “// TODO add comments so what this does is more 
understandable”

Sean

> On Jan 21, 2016, at 10:59 AM, Zachary Turner via lldb-dev 
>  wrote:
> 
> Also this is the same standard that applies to the rest of LLVM.  
> clang-format your patches.  Just because we haven't been consistently 
> following the rules until now doesn't mean we should continue to not follow 
> the rules going forward.  This way eventually the codebase slowly converges 
> towards a properly formatted one.  If clang-format does something that you 
> think looks awkward with respect to the surrounding code (perhaps within a 
> single logical block or whatever else) then just touch a line of code in the 
> surrounding area so that clang-format will do it too. Since it only formats 
> the differential, you have as much control as you need to produce something 
> that a) is consistent with the rules, and b) doesn't look awkward with 
> respect to surrounding code.
> 
> On Thu, Jan 21, 2016 at 10:11 AM Zachary Turner  > wrote:
> I'm not sure I agree.  I don't think anything will be awkwardly formatted 
> with regards to the rest of the file.  The biggest thing this is going to fix 
> are whitespace at the end of lines, line breakign conventions, and space 
> between function name and parentheses.
> 
> If we're not going to enforce a coding style, why have one at all?  
> clang-format enforces it.
> 
> On Thu, Jan 21, 2016 at 8:41 AM Todd Fiala  > wrote:
> Glad to see clang-format getting some improvements.
> 
> 
> 
> On Thu, Jan 7, 2016 at 10:30 AM, Zachary Turner  > wrote:
> As far as I'm aware, this is the last major incompatibility between LLDB's 
> style and clang-format's feature set.
> 
> I would appreciate it if more people could try it out with a few of their 
> patches, and let me know if any LLDB style incompatibilities arise in the 
> formatted code.
> 
> I would eventually like to move towards requiring that all patches be 
> clang-formatted before committing to LLDB.  
> 
> Question to the group on that last part.  I think if we have a large body of 
> code that is just getting a few tweaks to a method, having the patch run 
> through the formatter could lead to some pretty ugly code.  Imagine a few 
> lines of a file awkwardly formatted related to the rest of the file.  Since 
> we're not trying to reformat everything at once (which makes for difficult 
> code traceability), and given there was a large code base to start with 
> before LLDB was part of LLVM, I'm not sure we want a blanket statement that 
> says it must go through clang-format.  (I personally would be fine with doing 
> whole new functions and other logical blocks of code via clang-format when 
> inserted into existing code, but I think it probably extreme when we're 
> talking about new little sections within existing functions).
> 
> Thoughts?
> 
> 
> 
> -- 
> -Todd
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Sean Callanan via lldb-dev]

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, Pavel Labath via lldb-dev 
>  wrote:
> 
> Apparently, you can also disable the formatting of a piece of code by
> a magic comment. Could be quite useful for those tables. From the
> docs:
> -
> Clang-format understands also special comments that switch formatting
> in a delimited range. The code between a comment // clang-format off
> or /* clang-format off */ up to a comment // clang-format on or /*
> clang-format on */ will not be formatted. The comments themselves will
> be formatted (aligned) normally.
> -
> 
> 
> On 22 January 2016 at 17:09, Todd Fiala via lldb-dev
>  wrote:
>> Okay, thanks for the tip!
>> 
>> On Fri, Jan 22, 2016 at 8:32 AM, Zachary Turner  wrote:
>>> 
>>> By the way, one place where you are guaranteed to get undesirable results
>>> is where you have a large array formatted so that the columns line up.  Like
>>> in our options tables in the CommandObjects.  If you're using git, one way
>>> to avoid having clang-format touch these files is to commit that file by
>>> itself, then run git clang-format (since it only looks at staged files),
>>> then git commit --amend.  But of course that will gloss over any other
>>> changes you made to the file as well.  But in any case, it's another trick
>>> I've found useful occasionally.
>>> 
>>> On Fri, Jan 22, 2016 at 7:09 AM Kate Stone 
>>> wrote:
 
 Agreed.  My guidance has been that we go ahead and require submitters to
 use clang-format for patches, but to acknowledge that there may be cases
 where this produces undesirable results.  Manual formatting to correct 
 these
 issues is acceptable and should lead to discussions about concrete examples
 where the automated approach is imperfect.
 
 Kate Stone k8st...@apple.com
  Xcode Runtime Analysis Tools
 
 On Jan 21, 2016, at 9:46 PM, Todd Fiala via lldb-dev
  wrote:
 
 Okay, sounds like a reasonable thing to try.  We can always review it if
 it causes any real issues.
 
 On Thu, Jan 21, 2016 at 11:34 AM, Zachary Turner 
 wrote:
> 
> 
> 
> On Thu, Jan 21, 2016 at 11:18 AM Sean Callanan 
> wrote:
>> 
>> 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
>> DWARF parser).  Unfortunately, such functions tend to be the ones that
>> benefit most from clang-format.
>> 
>> In such a function, there’s a lot of useful history available via svn
>> blame that helps when fixing bugs.  My concern is that if someone
>> clang-formats this function after applying the kth fix, suddenly I've 
>> lost
>> convenient access to that history.  It’s only available with a fair 
>> amount
>> of pain, and this pain increases as more fixes are applied because now I
>> need to interleave the info before and after reformatting.
>> 
>> Would it be reasonable to mark such functions as “Don’t clang-format”?
>> That could be also interpreted as a “// TODO add comments so what this 
>> does
>> is more understandable”
> 
> 
> Well again by default it's only going to format the code you touch in
> yoru diff plus 1 or 2 surrounding lines.  So having it format an entire
> function is something you would have to explicitly go out of your way to 
> do.
> So it's a judgement call.  If you think the function would be better off
> clang-formatting the entire thing, do that.  If you just want to format 
> the
> lines you're touching because you were in there anyway, that's the default
> behavior.
 
 
 
 
 --
 -Todd
 
 ___
 
 
 lldb-dev mailing list
 lldb-dev@lists.llvm.org
 http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> 
>> 
>> 
>> 
>> --
>> -Todd
>> 
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Sean Callanan via lldb-dev]

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, 
but we’re probably not searching efficiently because this is super slow.

This would be an Everest regression.

I’m going to keep working on the original Radar because I haven’t gotten 
Brent’s backtrace yet; that said, this one is going to affect users’ perception 
of expression parser performance as well so I’ve filed it separately.

Sean
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Sean Callanan via lldb-dev]

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, 2016, at 11:22 AM, Ed Maste via lldb-dev  
> wrote:
> 
> The tests in lang/cpp/unicode-literals/TestUnicodeLiterals.py are
> marked with @unittest2.expectedFailure("rdar://18684408").
> 
> These tests are passing on FreeBSD:
> UNEXPECTED SUCCESS: test_and_run_command_dwarf
> (lang/c/const_variables/TestConstVariables.py)
> UNEXPECTED SUCCESS: test_expr1_dwarf
> (lang/cpp/unicode-literals/TestUnicodeLiterals.py)
> UNEXPECTED SUCCESS: test_expr2_dwarf
> (lang/cpp/unicode-literals/TestUnicodeLiterals.py)
> UNEXPECTED SUCCESS: test_expr3_dwarf
> (lang/cpp/unicode-literals/TestUnicodeLiterals.py)
> 
> The example in the test case works as expected:
> 
> (lldb) expr L"Hello"
> (const wchar_t [6]) $0 = L"Hello"
> 
> Are these passing on Linux as well?
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Sean Callanan via lldb-dev]

Ted,

I’m not sure who inside Clang actually sets the value ID – it’s the code 
generator’s job to make IR, we don’t construct it.
I would be fine with adding FunctionVal to the switch in CanResolveConstant, 
returning true.

Sean

> On Feb 23, 2016, at 3:28 PM, Ted Woodward  wrote:
> 
> Background: Hexagon clang doesn’t have JIT support, so lldb for Hexagon only 
> uses the IR Interpreter (Codeplay wrote it for us).
>  
> Sean, r260768 broke the expression parser with functions.
>  
> Without connecting to a target, I can’t get the info for main:
> (lldb) e main
> error: Can't run the expression locally: Interpreter doesn't handle one of 
> the expression's operands
>  
> Connected to a target, I can’t run a function:
> (lldb) e factorial(5)
> error: Can't run the expression locally: Interpreter doesn't handle one of 
> the expression's operands
>  
>  
> I’ve traced the failure to the call to CanResolveConstant() in 
> IRInterpreter::CanIntepret(). The failure happens on the 2nd operand. In the 
> working case, the Value ID is 0xa – Value::ConstantExprVal. In the failing 
> case, it is 0x5. Since it’s defined in a .def file, I can’t be sure, but my 
> guess is its Value::FunctionVal.
>  
>  
> Where is the Value ID set?
>  
>  
>  
> Some info from the expr log:
>  
> ; Function Attrs: nounwind
> define void @"_Z12$__lldb_exprPv"(i8* %"$__lldb_arg") #0 {
> entry:
>   %"$__lldb_arg.addr" = alloca i8*, align 4, !clang.decl.ptr !4
>   store i8* %"$__lldb_arg", i8** %"$__lldb_arg.addr", align 4
>   %0 = load i8, i8* @"_ZGVZ12$__lldb_exprPvE19$__lldb_expr_result", align 1
>   %guard.uninitialized = icmp eq i8 %0, 0
>   br i1 %guard.uninitialized, label %init.check, label %init.end
>  
> init.check:   ; preds = %entry
>   %call = call i32 @factorial(i32 5)
>   store i32 %call, i32* @"_ZZ12$__lldb_exprPvE19$__lldb_expr_result", align 4
>   store i8 1, i8* @"_ZGVZ12$__lldb_exprPvE19$__lldb_expr_result", align 1
>   br label %init.end
>  
> init.end: ; preds = %init.check, 
> %entry
>   ret void
> }
>  
>  
> Unsupported constant: declare i32 @factorial(i32) #1
>  
>  
> Ted
>  
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Sean Callanan via lldb-dev]

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 4

The store instruction should not have an operand of function type… right?

Sean

> On Feb 23, 2016, at 4:21 PM, Ted Woodward  wrote:
> 
> Unfortunately, that leads to another error, in the Instruction::Store case. 
> IRInterpreter::ResolveConstantValue() returns an error because it doesn’t 
> like the value id of FunctionVal. “Interpreter couldn't resolve a value 
> during execution”.
>  
> If I go back 1 commit from r260768 (r260767), it works. The value id is 0xa, 
> ConstantIntVal. So something in r260768 is either setting the value id to 
> 0x5, or keeping the value id from being set to 0xa.
>  
> Ted
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
>  
> From: scalla...@apple.com [mailto:scalla...@apple.com] 
> Sent: Tuesday, February 23, 2016 5:41 PM
> To: Ted Woodward
> Cc: LLDB
> Subject: Re: r260768 (Removed many JIT workarounds from IRForTarget) broke 
> expression parser with function on Hexagon
>  
> Ted,
>  
> I’m not sure who inside Clang actually sets the value ID – it’s the code 
> generator’s job to make IR, we don’t construct it.
> I would be fine with adding FunctionVal to the switch in CanResolveConstant, 
> returning true.
>  
> Sean
>  
>> On Feb 23, 2016, at 3:28 PM, Ted Woodward > > wrote:
>>  
>> Background: Hexagon clang doesn’t have JIT support, so lldb for Hexagon only 
>> uses the IR Interpreter (Codeplay wrote it for us).
>>  
>> Sean, r260768 broke the expression parser with functions.
>>  
>> Without connecting to a target, I can’t get the info for main:
>> (lldb) e main
>> error: Can't run the expression locally: Interpreter doesn't handle one of 
>> the expression's operands
>>  
>> Connected to a target, I can’t run a function:
>> (lldb) e factorial(5)
>> error: Can't run the expression locally: Interpreter doesn't handle one of 
>> the expression's operands
>>  
>>  
>> I’ve traced the failure to the call to CanResolveConstant() in 
>> IRInterpreter::CanIntepret(). The failure happens on the 2nd operand. In the 
>> working case, the Value ID is 0xa – Value::ConstantExprVal. In the failing 
>> case, it is 0x5. Since it’s defined in a .def file, I can’t be sure, but my 
>> guess is its Value::FunctionVal.
>>  
>>  
>> Where is the Value ID set?
>>  
>>  
>>  
>> Some info from the expr log:
>>  
>> ; Function Attrs: nounwind
>> define void @"_Z12$__lldb_exprPv"(i8* %"$__lldb_arg") #0 {
>> entry:
>>   %"$__lldb_arg.addr" = alloca i8*, align 4, !clang.decl.ptr !4
>>   store i8* %"$__lldb_arg", i8** %"$__lldb_arg.addr", align 4
>>   %0 = load i8, i8* @"_ZGVZ12$__lldb_exprPvE19$__lldb_expr_result", align 1
>>   %guard.uninitialized = icmp eq i8 %0, 0
>>   br i1 %guard.uninitialized, label %init.check, label %init.end
>>  
>> init.check:   ; preds = %entry
>>   %call = call i32 @factorial(i32 5)
>>   store i32 %call, i32* @"_ZZ12$__lldb_exprPvE19$__lldb_expr_result", align 4
>>   store i8 1, i8* @"_ZGVZ12$__lldb_exprPvE19$__lldb_expr_result", align 1
>>   br label %init.end
>>  
>> init.end: ; preds = %init.check, 
>> %entry
>>   ret void
>> }
>>  
>>  
>> Unsupported constant: declare i32 @factorial(i32) #1
>>  
>>  
>> Ted
>>  
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
>> Linux Foundation Collaborative Project

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Sean Callanan via lldb-dev]

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 (!frame.EvaluateValue(I, val, module))
{
error.SetErrorToGenericError();
error.SetErrorString("unable to get address of function");
return false;
}
–
It assumes that getCalledValue returns something we can evaluate – which used 
to be a function pointer so everything was fine.
We have to modify EvaluateValue to, when it encounters a FunctionVal, look up 
the corresponding symbol (using IRExecutionUnit::FindSymbol(), ideally) and 
return a Scalar containing the function pointer.
As a first step, I’d suggest trying to make EvaluateValue return true but just 
put nullptr into the Scalar when it gets a FunctionVal – does that result (as 
I’d expect) in a bad function call, or do we still get some kind of “doesn’t 
handle” error?

Sean

> On Feb 24, 2016, at 2:17 PM, Ted Woodward  wrote:
> 
> I did some digging and found where the ID is being changed from 0x5 to 0xa in 
> the original code.
>  
> IRForTarget::runOnModule() calls ResolveFunctionPointers(), which gets a 
> Constant * from BuildFunctionPointer(). This Value has an ID of 0xa, and 
> runOnModule() then calls the original Function’s replaceAllUsesWith(), 
> passing in the new Value, changing ID from 0x5 to 0xa.
>  
> If I comment out the call to ResolveFunctionPointer() in the original code, I 
> get the same error as the current code: “error: Can't run the expression 
> locally: Interpreter doesn't handle one of the expression's operands”
>  
> So I went to r260768 and added back in the call to ResolveFunctionPointer(), 
> as well as functions that it depended on:
> ClangExpressionDeclMap::FindCodeSymbolInContext()
> ClangExpressionDeclMap::FindBestAlternateMangledName()
> ClangExpressionDeclMap::GetFunctionAddress()
> IRForTarget::GetFunctionAddress()
> IRForTarget::BuildFunctionPointer()
> I commented out the call to RegisterFunctionMetadata() since it didn’t seem 
> to matter.
>  
> After those changes, I was able to print out main’s info and call functions 
> with the expression parser.
>  
> Is there anything in these functions that I can get rid of, or is handled by 
> newer code?
>  
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
>  
> From: scalla...@apple.com [mailto:scalla...@apple.com] 
> Sent: Tuesday, February 23, 2016 6:38 PM
> To: Ted Woodward
> Cc: LLDB
> Subject: Re: 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 4
>  
> The store instruction should not have an operand of function type… right?
>  
> Sean
>  
>> On Feb 23, 2016, at 4:21 PM, Ted Woodward > > wrote:
>>  
>> Unfortunately, that leads to another error, in the Instruction::Store case. 
>> IRInterpreter::ResolveConstantValue() returns an error because it doesn’t 
>> like the value id of FunctionVal. “Interpreter couldn't resolve a value 
>> during execution”.
>>  
>> If I go back 1 commit from r260768 (r260767), it works. The value id is 0xa, 
>> ConstantIntVal. So something in r260768 is either setting the value id to 
>> 0x5, or keeping the value id from being set to 0xa.
>>  
>> Ted
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
>> Linux Foundation Collaborative Project
>>  
>> From: scalla...@apple.com  
>> [mailto:scalla...@apple.com ] 
>> Sent: Tuesday, February 23, 2016 5:41 PM
>> To: Ted Woodward
>> Cc: LLDB
>> Subject: Re: r260768 (Removed many JIT workarounds from IRForTarget) broke 
>> expression parser with function on Hexagon
>>  
>> Ted,
>>  
>> I’m not sure who inside Clang actually sets the value ID – it’s the code 
>> generator’s job to make IR, we don’t construct it.
>> I would be fine with adding FunctionVal to the switch in CanResolveConstant, 
>> returning true.
>>  
>> Sean
>>  
>>> On Feb 23, 2016, at 3:28 PM, Ted Woodward >> > wrote:
>>>  
>>> Background: Hexagon clang doesn’t have JIT support, so lldb for Hexagon 
>>> only uses the IR Interpreter (Codeplay wrote it for us).
>>>  
>>> Sean, r260768 broke the expression parser with functions.
>>>  
>>> Without connecting to a target, I can’t get the 

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

[Sean Callanan via lldb-dev]

I should clarify: it’s expected that there is a FunctionVal there.  This is 
much better when JITting later on, and the transform from FunctionVal to a 
function pointer was a hack in IRForTarget.
The IRInterpreter just has to handle FunctionVals, as I just outlined.

Sean

> On Feb 24, 2016, at 2:36 PM, Sean Callanan via lldb-dev 
>  wrote:
> 
> 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 (!frame.EvaluateValue(I, val, module))
> {
> error.SetErrorToGenericError();
> error.SetErrorString("unable to get address of function");
> return false;
> }
> –
> It assumes that getCalledValue returns something we can evaluate – which used 
> to be a function pointer so everything was fine.
> We have to modify EvaluateValue to, when it encounters a FunctionVal, look up 
> the corresponding symbol (using IRExecutionUnit::FindSymbol(), ideally) and 
> return a Scalar containing the function pointer.
> As a first step, I’d suggest trying to make EvaluateValue return true but 
> just put nullptr into the Scalar when it gets a FunctionVal – does that 
> result (as I’d expect) in a bad function call, or do we still get some kind 
> of “doesn’t handle” error?
> 
> Sean
> 
>> On Feb 24, 2016, at 2:17 PM, Ted Woodward > <mailto:ted.woodw...@codeaurora.org>> wrote:
>> 
>> I did some digging and found where the ID is being changed from 0x5 to 0xa 
>> in the original code.
>>  
>> IRForTarget::runOnModule() calls ResolveFunctionPointers(), which gets a 
>> Constant * from BuildFunctionPointer(). This Value has an ID of 0xa, and 
>> runOnModule() then calls the original Function’s replaceAllUsesWith(), 
>> passing in the new Value, changing ID from 0x5 to 0xa.
>>  
>> If I comment out the call to ResolveFunctionPointer() in the original code, 
>> I get the same error as the current code: “error: Can't run the expression 
>> locally: Interpreter doesn't handle one of the expression's operands”
>>  
>> So I went to r260768 and added back in the call to ResolveFunctionPointer(), 
>> as well as functions that it depended on:
>> ClangExpressionDeclMap::FindCodeSymbolInContext()
>> ClangExpressionDeclMap::FindBestAlternateMangledName()
>> ClangExpressionDeclMap::GetFunctionAddress()
>> IRForTarget::GetFunctionAddress()
>> IRForTarget::BuildFunctionPointer()
>> I commented out the call to RegisterFunctionMetadata() since it didn’t seem 
>> to matter.
>>  
>> After those changes, I was able to print out main’s info and call functions 
>> with the expression parser.
>>  
>> Is there anything in these functions that I can get rid of, or is handled by 
>> newer code?
>>  
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
>> Linux Foundation Collaborative Project
>>  
>> From: scalla...@apple.com <mailto:scalla...@apple.com> 
>> [mailto:scalla...@apple.com <mailto:scalla...@apple.com>] 
>> Sent: Tuesday, February 23, 2016 6:38 PM
>> To: Ted Woodward
>> Cc: LLDB
>> Subject: Re: 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 4
>>  
>> The store instruction should not have an operand of function type… right?
>>  
>> Sean
>>  
>>> On Feb 23, 2016, at 4:21 PM, Ted Woodward >> <mailto:ted.woodw...@codeaurora.org>> wrote:
>>>  
>>> Unfortunately, that leads to another error, in the Instruction::Store case. 
>>> IRInterpreter::ResolveConstantValue() returns an error because it doesn’t 
>>> like the value id of FunctionVal. “Interpreter couldn't resolve a value 
>>> during execution”.
>>>  
>>> If I go back 1 commit from r260768 (r260767), it works. The value id is 
>>> 0xa, ConstantIntVal. So something in r260768 is either setting the value id 
>>> to 0x5, or keepi

Re: [lldb-dev] LLDB Evolution

[Sean Callanan via lldb-dev]

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 
>  wrote:
> 
> 
>> On Aug 11, 2016, at 7:41 AM, Pavel Labath  wrote:
>> 
>> I just committed another  header cleanup commit, which makes lldb
>> clang-format-immune ( = it still compiles after a full reformat) on
>> linux. Other OS's are still likely to have some missed dependencies.
> 
> Nice!
> 
>> However, when I tried running the test suite I got about 150 failures.
>> Based on a sample of the errors, it looks like the problem is that
>> clang format messes up the "// Place breakpoint here" annotations we
>> use in the tests.
>> Therefore, I propose to apply the clang-format to the lldb source code
>> only as a first step. After that, as a second step, we can go through
>> the tests and fix them up so that the comment markers are where we
>> expect them to be.
> 
> Personally, I think that reformatting is most valuable for the debugger code 
> itself.  The testsuite following standards seems like a separable issue, and 
> much lower priority.
> 
> -Chris
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Sean Callanan via lldb-dev]

I'll only comment on the stuff that affects me.

> Use llvm streams instead of lldb::StreamString
> Supports output re-targeting (stderr, stdout, std::string, etc), printf style 
> formatting, and type-safe streaming operators.
> Interoperates nicely with many existing llvm utility classes
> Risk: 4
> Impact: 5
> Difficulty / Effort: 7

I don't like that llvm's stringstream needs to be babied to make it produce its 
string.  You have to wrap it and then flush it and then read the string.  Maybe 
a subclass could be made that wraps its own string and flushes automatically on 
read?

> Use llvm::Error instead of lldb::Error
> llvm::Error is an error class that *requires* you to check whether it 
> succeeded or it will assert.  In a way, it's similar to a C++ exception, 
> except that it doesn't come with the performance hit associated with 
> exceptions.  It's extensible, and can be easily extended to support the 
> various ways LLDB needs to construct errors and error messages.
> Would need to first rename lldb::Error to LLDBError so that te conversion 
> from LLDBError to llvm::Error could be done incrementally.
> Risk: 7
> Impact: 7
> Difficulty / Effort: 8

This would help me a lot if the underlying Clang APIs implemented it.  
Unfortunately the expression parser mainly just receives diagnostics and has to 
deal with them.
From the perspective of internal use, I could live with llvm::Error, 
particularly if it gets us 3f.

> ArrayRef instead of const void *, len everywhere
> Same analysis as StringRef
> MutableArrayRef instead of void *, len everywhere
> Same analysis as StringRef

At one point I made a templated mixin class that would make everything that 
vended GetNum*/Get*AtIndex functions also vend an iterator.  Hopefully we can 
get that implemented everywhere.

> Testing - Our testing infrastructure is unstable, and our test coverage is 
> lacking.  We should take steps to improve this.
> Port as much as possible to lit
> Simple tests should be trivial to port to lit today.  If nothing else this 
> serves as a proof of concept while increasing the speed and stability of the 
> test suite, since lit is a more stable harness.
> Separate testing tools
> One question that remains open is how to represent the complicated needs of a 
> debugger in lit tests.  Part a) above covers the trivial cases, but what 
> about the difficult cases?  In https://reviews.llvm.org/D24591 
>  a number of ideas were discussed.  We 
> started getting to this idea towards the end, about a separate tool which has 
> an interface independent of the command line interface and which can be used 
> to test.  lldb-mi was mentioned.  While I have serious concerns about lldb-mi 
> due to its poorly written and tested codebase, I do agree in principle with 
> the methodology.  In fact, this is the entire philosophy behind lit as used 
> with LLVM, clang, lld, etc.  
> 
> I don’t take full credit for this idea.  I had been toying with a similar 
> idea for some time, but it was further cemented in an offline discussion with 
> a co-worker.  
> 
> There many small, targeted tools in LLVM (e.g. llc, lli, llvm-objdump, etc) 
> whose purpose are to be chained together to do interesting things.  Instead 
> of a command line api as we think of in LLDB where you type commands from an 
> interactive prompt, they have a command line api as you would expect from any 
> tool which is launched from a shell.
> 
> I can imagine many potential candidates for lldb tools of this nature.  Off 
> the top of my head:
> lldb-unwind - A tool for testing the unwinder.  Accepts byte code as input 
> and passes it through to the unwinder, outputting a compressed summary of the 
> steps taken while unwinding, which could be pattern matched in lit.  The 
> output format is entirely controlled by the tool, and not by the unwinder 
> itself, so it would be stable in the face of changes to the underlying 
> unwinder.  Could have various options to enable or disable features of the 
> unwinder in order to force the unwinder into modes that can be tricky to 
> encounter in the wild.
> lldb-symbol - A tool for testing symbol resolution.  Could have options for 
> testing things like:
> Determining if a symbol matches an executable
> looking up a symbol by name in the debug info, and mapping it to an address 
> in the process.  
> Displaying candidate symbols when doing name lookup in a particular scope 
> (e.g. while stopped at a breakpoint).
> lldb-breakpoint - A tool for testing breakpoints and stepping.  Various 
> options could include:
> Set breakpoints and out addresses and/or symbol names where they were 
> resolved to.
> Trigger commands, so that when a breakpoint is hit the tool could 
> automatically continue and try to run to another breakpoint, etc.
> options to inspect certain useful pieces of state about an inferior, to be 
> matched in lit. 
> lldb-interpreter - tests the jitter etc.  I don’t know much about this, but

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

[Sean Callanan via lldb-dev]

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 not 100% sure, 
so let me crash if I'm wrong..." – if we're making that admission and not doing 
error handling, we're already a little shady.

Sean
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Sean Callanan via lldb-dev]

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 easier to just change the macro, but I 
> would just do what LLVM does as long as you don't mind the extra work.
> 
> On Tue, Sep 27, 2016 at 3:01 PM Daniel Austin Noland via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> 
> 
> On 09/27/2016 03:37 PM, Enrico Granata wrote:
>> 
>>> On Sep 27, 2016, at 1:09 PM, Daniel Austin Noland via lldb-dev 
>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>> 
>>> * Prefer explicitly deleted copy ctor / assignments over multiline macro 
>>> DISALLOW_COPY_AND_ASSIGN
>> 
>> 
>> Why not just move DISALLOW_COPY_AND_ASSIGN over to using =delete ? That 
>> seems like a trivial change..
> 
> That was my first thought as well.  Still, I personally try to avoid macros.  
> On the other hand that one is simple enough that it may be justified.
> 
>> 
>> Thanks,
>> - Enrico
>> 📩 egranata@.com ☎️ 27683
>> 
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Sean Callanan via lldb-dev]

The issue I have with the DISALLOW_ macro is that when you're looking to see 
what sort of constructors etc. are possible, you now have to look through a 
macro.  Personally, I like to see what constructors are available on an object 
in one list, and not have to guess about whether e.g. a move constructor is 
present or disallowed.

Sean

> On Sep 27, 2016, at 3:24 PM, Jim Ingham  wrote:
> 
> Why?  The 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 
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>> 
>> 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 
>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>> 
>>> FWIW LLVM removed all it's disallow copy / assign macros in favor of 
>>> explicitly writing it.  I agree it's easier to just change the macro, but I 
>>> would just do what LLVM does as long as you don't mind the extra work.
>>> 
>>> On Tue, Sep 27, 2016 at 3:01 PM Daniel Austin Noland via lldb-dev 
>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>> 
>>> 
>>> On 09/27/2016 03:37 PM, Enrico Granata wrote:
>>>> 
>>>>> On Sep 27, 2016, at 1:09 PM, Daniel Austin Noland via lldb-dev 
>>>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>>>> 
>>>>> * Prefer explicitly deleted copy ctor / assignments over multiline macro 
>>>>> DISALLOW_COPY_AND_ASSIGN
>>>> 
>>>> 
>>>> Why not just move DISALLOW_COPY_AND_ASSIGN over to using =delete ? That 
>>>> seems like a trivial change..
>>> 
>>> That was my first thought as well.  Still, I personally try to avoid 
>>> macros.  On the other hand that one is simple enough that it may be 
>>> justified.
>>> 
>>>> 
>>>> Thanks,
>>>> - Enrico
>>>> 📩 egranata@.com  ☎️ 27683
>>>> 
>>> 
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
>> 
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Sean Callanan via lldb-dev]

That solves the problem of excising the macros, but it replaces it with now 
having to look at a superclass.  Honestly that sounds like six one way, a half 
dozen the other.
I wouldn't want this great overall list of improvements to get sidetracked over 
bike shedding this, however.  I'm fine with whatever approach is used, even if 
it's the status quo.

Sean

> On Sep 27, 2016, at 3:43 PM, Zachary Turner  wrote:
> 
> One solution I've seen (I think boost does this as well) is to make a utility 
> class called noncopyable that you can privately inherit from:
> 
> class noncopyable {
> public:
>noncopyable(const noncopyable &) = delete;
>noncopyable &operator=(const noncopyable &other) = delete;
> };
> 
> class Foo : private noncopyable {
> };
> 
> 
> 
> On Tue, Sep 27, 2016 at 3:29 PM Sean Callanan  <mailto:scalla...@apple.com>> wrote:
> The issue I have with the DISALLOW_ macro is that when you're looking to see 
> what sort of constructors etc. are possible, you now have to look through a 
> macro.  Personally, I like to see what constructors are available on an 
> object in one list, and not have to guess about whether e.g. a move 
> constructor is present or disallowed.
> 
> Sean
> 
>> On Sep 27, 2016, at 3:24 PM, Jim Ingham > <mailto:jing...@apple.com>> wrote:
>> 
>> Why?  The 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 
>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>> 
>>> 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 
>>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>>> 
>>>> FWIW LLVM removed all it's disallow copy / assign macros in favor of 
>>>> explicitly writing it.  I agree it's easier to just change the macro, but 
>>>> I would just do what LLVM does as long as you don't mind the extra work.
>>>> 
>>>> On Tue, Sep 27, 2016 at 3:01 PM Daniel Austin Noland via lldb-dev 
>>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>>> 
>>>> 
>>>> On 09/27/2016 03:37 PM, Enrico Granata wrote:
>>>>> 
>>>>>> On Sep 27, 2016, at 1:09 PM, Daniel Austin Noland via lldb-dev 
>>>>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>>>>> 
>>>>>> * Prefer explicitly deleted copy ctor / assignments over multiline macro 
>>>>>> DISALLOW_COPY_AND_ASSIGN
>>>>> 
>>>>> 
>>>>> Why not just move DISALLOW_COPY_AND_ASSIGN over to using =delete ? That 
>>>>> seems like a trivial change..
>>>> 
>>>> That was my first thought as well.  Still, I personally try to avoid 
>>>> macros.  On the other hand that one is simple enough that it may be 
>>>> justified.
>>>> 
>>>>> 
>>>>> Thanks,
>>>>> - Enrico
>>>>> 📩 egranata@.com <> ☎️ 27683
>>>>> 
>>>> 
>>>> ___
>>>> lldb-dev mailing list
>>>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>>>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
>>>> ___
>>>> lldb-dev mailing list
>>>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>>>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
>>> 
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
>> 
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Sean Callanan via lldb-dev]

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.  At present, each connection to the lldb-rpc-server gets its 
> own SBDebugger, so you wouldn't be able to talk to the debugger that Xcode is 
> using for its process.
> 
> Even if that was changed, then you'd run into other problems, for instance, 
> at present only one Listener can wait for process events from the debugger, 
> so you would not be able to control execution or coordinate with Xcode's 
> running of the process.  But this is probably just the tip of the iceberg of 
> things that would go wrong if you try to do this.  
> 
> If you have lots of resources to devote to hacking on lldb itself, I'm sure 
> you could make this work, but this is a very tricky part of lldb, so the 
> engineering work would be non-trivial to say the least.  I don't know your 
> circumstances, but I doubt it would end up being worthwhile for you.
> 
> Enrico's suggestion of making Python commands to do the job is probably the 
> best way to go.
> 
> Note, it used to be tricky to get a plain command tool (lldb-rpc-server) to 
> connect to the Window Server and put up UI.  I haven't tried that since I 
> worked on Tcl/Tk way back in the day, so it may be easier now.  But you 
> should probably also experiment with that to make sure that's possible before 
> you go too far down this route.
> 
> Jim
> 
> 
>> On Oct 7, 2016, at 12:05 PM, Rex Fenley via lldb-dev 
>>  wrote:
>> 
>> https://media4.giphy.com/media/l2Je27KfKp8x71qAo/200.gif
>> 
>> On Fri, Oct 7, 2016 at 12:01 PM, Enrico Granata  wrote:
>> It is my understanding that this is not possible in the current architecture
>> 
>>> On Oct 7, 2016, at 11:55 AM, Rex Fenley  wrote:
>>> 
>>> We expect to have a rich user experience as this tool progresses, using 
>>> Python to generate UI will limit our development process. It would be much 
>>> simpler if we could communicate with Xcode's lldb directly from our 
>>> application.
>>> 
>>> On Fri, Oct 7, 2016 at 11:33 AM, Enrico Granata  wrote:
>>> I can see a couple of avenues for your use case:
>>> 
>>> - you can write custom LLDB commands (obligatory reference: 
>>> http://lldb.llvm.org/python-reference.html) and have your users type these 
>>> via the console instead of by clicking buttons
>>> - you could write a Python script that pops up extra UI and have your 
>>> buttons run as part of LLDB that way. I have admittedly never tried to do 
>>> this, and it might require some tinkering, but in theory I believe it 
>>> should be possible
>>> 
>>> Personally, I'd rather much have console commands I can type instead of a 
>>> magic separate UI that might even be hidden underneath other windows or 
>>> hiding useful information unless I drag it out of the way, but then it's 
>>> annoying to reach for when I need it, ..., but that's me...
>>> 
 On Oct 7, 2016, at 11:27 AM, Rex Fenley  wrote:
 
 I'm trying to build a separate debugging tool that can be used in unison 
 with Xcode it will provide buttons that are shortcuts to lldb scripts we 
 write.
 
 On Fri, Oct 7, 2016 at 10:45 AM, Enrico Granata  wrote:
 I am gonna echo Kate's question, but delve one level deeper
 
 Why do you want to send commands to LLDB from a different process?
 
 We have a bunch of different extension points in LLDB, so it's possible 
 that what you're trying to do is actually already possible
 
> On Oct 7, 2016, at 10:41 AM, Rex Fenley via lldb-dev 
>  wrote:
> 
> Hi Kate,
> 
> I'm trying to connect to the running instance of lldb in Xcode to send 
> commands to it from a different process :)
> 
> On Fri, Oct 7, 2016 at 10:27 AM, Kate Stone  wrote:
> The RPC mechanism used in Xcode 8 is not a part of the open source LLDB 
> project and should be treated as an implementation detail of Xcode.  What 
> are you trying to accomplish?
> 
> Kate Stone k8st...@apple.com
>  Xcode Low Level Tools
> 
>> On Oct 6, 2016, at 6:11 PM, Rex Fenley via lldb-dev 
>>  wrote:
>> 
>> Hi! I'm trying to connect to Xcode's lldb rpc server but I'm having 
>> trouble.
>> 
>> This doesn't seem to work to list the hosts.
>> rpcinfo -p lldb-rpc-server
>> 
>> Can't contact rpcbind on lldb-rpc-server
>> 
>> 
>> rpcinfo: RPC: Unknown host
>> 
>> Am I doing this correctly?
>> 
>> -- 
>> Rex Fenley  |  IOS DEVELOPER
>> 
>> 
>> Remind.com |  BLOG  |  FOLLOW US  |  LIKE US
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
> 
> 
> 
> -- 
> Rex Fenley  |  IOS DEVELOPER
>

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

[Sean Callanan via lldb-dev]

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 {

  return ProtectedGetPropertyAtIndex(idx);
}

Its callersgoto some trouble to collect and pass around the 
ExecutionContext (e.g., GetSubValue passes it around everywhere, 
GetPropertyAtrIndexAs* has to keep iteverywhere, theDump mechanism 
passes around ExecutionContexts, etc.)


Aside from calling this function with completely ignores the 
ExecutionContext, I don't see the execution contexts getting used 
anywhere.  Is this a remnant from old code?


Sean

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Sean Callanan via lldb-dev]

I was evaluating whether to provide one in a target setting, and I 
decidednot to.


Then I was looking to see why anyone wouild, and I couldn't find anyone 
actually using it.


It's a little painful to see it passed around everywhere rather 
thanstored by Process or Target, the two thingsthat care...but it's not 
getting in the way of my work.


Sean

On 7/21/17 4:51 PM, Jim Ingham wrote:

Was this just curiosity, or was this getting in your way somehow?

Jim


On Jul 21, 2017, at 4:50 PM, Jim Ingham via lldb-dev  
wrote:



On Jul 21, 2017, at 4:41 PM, Sean Callanan via lldb-dev 
 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 ExecutionContext *exe_ctx, bool will_modify, uint32_t idx) const {
  return ProtectedGetPropertyAtIndex(idx);
}

Its callers  go to some trouble to collect and pass around the ExecutionContext 
(e.g., GetSubValue passes it around everywhere, GetPropertyAtrIndexAs* has to 
keep it everywhere, the Dump mechanism passes around ExecutionContexts, etc.)

Aside from calling this function with completely ignores the ExecutionContext, 
I don't see the execution contexts getting used anywhere.  Is this a remnant 
from old code?

For instance (from Process.cpp):

class ProcessOptionValueProperties : public OptionValueProperties {
public:
  ProcessOptionValueProperties(const ConstString &name)
  : OptionValueProperties(name) {}

  // This constructor is used when creating ProcessOptionValueProperties when it
  // is part of a new lldb_private::Process instance. It will copy all current
  // global property values as needed
  ProcessOptionValueProperties(ProcessProperties *global_properties)
  : OptionValueProperties(*global_properties->GetValueProperties()) {}

  const Property *GetPropertyAtIndex(const ExecutionContext *exe_ctx,
 bool will_modify,
 uint32_t idx) const override {
// When getting the value for a key from the process options, we will always
// try and grab the setting from the current process if there is one. Else
// we just
// use the one from this instance.
if (exe_ctx) {
  Process *process = exe_ctx->GetProcessPtr();
  if (process) {
ProcessOptionValueProperties *instance_properties =
static_cast(
process->GetValueProperties().get());
if (this != instance_properties)
  return instance_properties->ProtectedGetPropertyAtIndex(idx);
  }
}
return ProtectedGetPropertyAtIndex(idx);
  }
};

That's what tells you whether to use the global process property, or this 
process specific one.  Ditto for Thread properties.

Jim



Sean
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB tests

[Sean Callanan via lldb-dev]

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]
 * https://ci.swift.org/view/All/job/oss-lldb-incremental-osx/ [OS X]
 * https://ci.swift.org/view/All/job/oss-lldb-incremental-linux-ubuntu-16_10/
   [Linux]

There are many more bots, as you'll discover browsing around, but these 
should give you a good idea of the health of our testsuite at any given 
time.


Sean

On 7/24/17 3:03 AM, Steve Trotter via lldb-dev wrote:

Hi all,

I'm fairly new to LLVM and LLDB, I became interested in this project 
about 3 months back and I'm hoping to be able to contribute to 
improving LLDB in time. I've been trying to get to grips with the code 
and have been looking into the tests as a rough guide to how things 
work, however I have some questions about the test suites in LLDB.


It seems to me that we essentially have tests ran by the LIT runner 
from LLVM core and tests ran by an LLDB specific python script 
`dotest.py`. I notice that on the test page for LLDB they refer to the 
`dotest.py` tests ran by a `ninja --check-lldb` but not the latter. I 
also notice in an email titled "lldb-server tests" from Paval Labath 
on 15th May 2017 suggests that the plan long term is to be to move 
purely to using LIT style testing. Is this correct or have I 
misunderstood? I did have a look in buildbot to see what tests are 
being used and I can only find the `dotest.py` style tests, however 
it's possible I've misunderstood something here, the 
"lldb-x86_64-ubuntu-14.04-cmake" is not easy to make sense of I'm afraid.


Also there seems only to be one test for lldb-server in the LIT suite 
at present. Is there a reason for this at present, possibly along the 
lines of we're still waiting for the ability to run tests remotely 
using LIT as per this email thread? I couldn't find an obvious answer 
as to whether a design was agreed upon for this and/or the work 
completed, maybe it's an ongoing question still.


Finally, I do see failures myself in both of these tests from the 
latest build. I do tend to limit it to compiling only for X86 target 
and I suspect this may be related, or possibly just something odd with 
my build system anyway. Obviously in an ideal world these tests should 
always pass but does anyone else have similar problems? I assume they 
tend to pass for the core developers as it seems to be fairly LLVM 
centric to ensure passing tests for new bits of work. I can send the 
outputs of the failing tests if it's thought useful.


Many thanks for your time,

Steve



___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Symbolic information in disassembler output

[Sean Callanan via lldb-dev]

Greg is right that this was a libedis feature and has no equivalent in 
LLDB today.


MCInst, however, doesn't have enough information by itself to do this.  
The reason is that for many things that are considered "operands," the 
MCInst has several underlying operands.  For example, an operand that 
was expressed as a register + an offset would be represented in MCInst 
as a register operand and in immediate operand, and only correlating the 
opcode with the LLVM instruction tables (and possibly some special 
knowledge) would tell you that the two belong together.


Additionally, libedis could express the semantics of the instruction 
operands (e.g., "this is a source operand and represents the result of 
dereferncing rbp - 4") , and inform the client what ranges of characters 
in the generated string represented each high level operand.  Both of 
these features are not exposed anywhere at the moment, and in fact the 
underlying knowledge was lost when the edis TableGen backend was deprecated.


There are a few LLDB features that reads instructions and attempt to 
interpret them:


 * The fast unwinder looks for specific bit patterns (see
   UnwindAssembly_x86::GetFastUnwindPlan in UnwindAssembly-x86.cpp);
 * The ARM instruction emulator has its own home-grown instruction
   table (see EmulateInstructionARM64.cpp); and
 * The crash diagnose functionality actually parses the output strings
   from the disassembler (see DoGuessValueAt in StackFrame.cpp).

Sean

On 8/31/17 11:09 AM, Greg Clayton via lldb-dev wrote:
I believe libedis was deprecated many years ago and hasn't returned. 
We use the standard LLVM disassembler, so any features need to be 
built into llvm::MCInst.


On Aug 31, 2017, at 10:42 AM, Tatyana Krasnukha via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:


Hello,
As I understand it, old disassembler (based on libedis) could print 
symbolic information instead/beside address operand of an 
instruction. And it looks like there is not such ability in 
disassembler now. Is thisresponsibility shifted on some other 
component of lldb? Or it was considered as useless and was removed at 
all?

Thanks,
Tatyana
___
lldb-dev mailing list
lldb-dev@lists.llvm.org 
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev




___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev