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

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 tha

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] * https://ci.swift.org/view/All/job/oss

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

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 l

[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. At present, each connectio

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

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 everyw

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

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

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 easier to just change the ma

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 not

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

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:

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 > wrote: > >

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 > 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; >

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 (!frame.Evalu

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 4

Re: [lldb-dev] 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

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, 201

[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, Pave

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 Zachary Turner