Re: [lldb-dev] Module Cache improvements - RFC

For progress purposes in Android Studio we listen on eBroadcastBitModulesLoaded coming from the target so we can report about every loaded SO. On Tue, Feb 23, 2016 at 10:00 AM, Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I believe this is already done. > > I am guessing the

Re: [lldb-dev] No stopping event during launch(stop_at_entry=True) on Linux?

I am not sure. From the output, it seems lldb does stop at the entry point(because you can issue "bt" command to dump the stack) in both platforms; the problem seems to be that it did not emit the stopped event for its stop on linux. On Tue, Feb 23, 2016 at 2:03 PM, Jim Ingham

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

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

Re: [lldb-dev] How to use the C++ API? No useful documentation?

I need to spend some time writing this up, but until then here is some info. We created a python script that uses the LLDB public API to grab async events so people can see how to do things: svn cat http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/process_events.py If you look in

Re: [lldb-dev] No stopping event during launch(stop_at_entry=True) on Linux?

Makes sense, will file a bug for it. Sent from my iPad > On Feb 23, 2016, at 5:10 PM, Jim Ingham wrote: > > That also is a bug. If it is going to do a public stop, it has to send a > stop event. > > Jim > >> On Feb 23, 2016, at 2:52 PM, Jeffrey Tan

Re: [lldb-dev] Module Cache improvements - RFC

Yes we already have a disk cache on the host. I agree with you that waiting 30s at the first startup shouldn't be an issue in general (Pavel isn't sharing my opinion). The only catch is that in case of iOS there are only a few different builds released so if you downloaded the modules once then I

Re: [lldb-dev] Module Cache improvements - RFC

On Tue, Feb 23, 2016 at 1:21 PM, Tamas Berghammer via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Yes we already have a disk cache on the host. I agree with you that > waiting 30s at the first startup shouldn't be an issue in general (Pavel > isn't sharing my opinion). The only catch is that in

Re: [lldb-dev] Module Cache improvements - RFC

I believe this is already done. I am guessing the main issue is this happens on the first time you debug to a device you and up with a 30 second delay with no feedback as to what is going on. So you say "launch" and then 35 seconds later you hit your breakpoint at main. In Xcode we solve this

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

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

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

[lldb-dev] [Bug 26289] lldb host crashes with allocation failure when attaching to a remote android target

https://llvm.org/bugs/show_bug.cgi?id=26289 Luke Drummond changed: What|Removed |Added Resolution|FIXED |INVALID -- You

[lldb-dev] [Bug 26710] New: TestInlines fails on Linux with gcc

https://llvm.org/bugs/show_bug.cgi?id=26710 Bug ID: 26710 Summary: TestInlines fails on Linux with gcc Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal

[lldb-dev] [Bug 26289] lldb host crashes with allocation failure when attaching to a remote android target

https://llvm.org/bugs/show_bug.cgi?id=26289 Luke Drummond changed: What|Removed |Added Status|NEW |RESOLVED

Re: [lldb-dev] [Release-testers] [3.8 Release] RC3 has been tagged

On Wednesday, February 24, 2016 05:51 AM, Hans Wennborg via Release-testers wrote: Dear testers, Release Candidate 3 has just been tagged [1]. Please build, test, and upload to the sftp. On Ubuntu 15.10 x86_64 I got: Failing Tests (2): MemorySanitizer :: Linux/forkpty.cc

Re: [lldb-dev] [Openmp-dev] [3.8 Release] Release status

On Mon, Feb 22, 2016 at 11:47 PM, Ismail Donmez wrote: > On Tue, Feb 23, 2016 at 5:48 AM, Hans Wennborg via Openmp-dev > wrote: >> I had hoped to tag rc3 today (I feel like I've said this a lot >> lately), but it's at least really, really close. I'm

[lldb-dev] How to use the C++ API? No useful documentation?

Hello, I am currently working on an IDE for C++ and I would like to integrate lldb as a debugger using the C++ API but it has been difficult for me to understand the architecture because there is no documentation available (except doxygen which isn't helpful at all). I am at the point

[lldb-dev] [3.8 Release] RC3 has been tagged

Dear testers, Release Candidate 3 has just been tagged [1]. Please build, test, and upload to the sftp. If there are no regressions from previous release candidates, this will be the last release candidate before the final release. Release notes can still go into the branch. Thanks again for

Re: [lldb-dev] How to use the C++ API? No useful documentation?

The Python API is pretty much a mirror of the C++ API's. The process_events.py example: http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/process_events.py should give you a sense of how the broadcasters & listeners are used. Translating that from Python to C++ is quite

[lldb-dev] No stopping event during launch(stop_at_entry=True) on Linux?

Hi, I have got lldb launch working fine on my macbook for sometime. But when I try the same code on Linux, it failed to emit any stopping events during initial launch. When I run the reproduce code(listed at the end), I got the following different results: The key difference is that Macbook

Re: [lldb-dev] Module Cache improvements - RFC

> On Feb 23, 2016, at 10:31 AM, Nico Weber wrote: > > On Tue, Feb 23, 2016 at 1:21 PM, Tamas Berghammer via lldb-dev > wrote: > Yes we already have a disk cache on the host. I agree with you that waiting > 30s at the first startup shouldn't be an

Re: [lldb-dev] No stopping event during launch(stop_at_entry=True) on Linux?

If the linux side is not obeying "stop_at_entry" then that is a bug. Jim > On Feb 23, 2016, at 1:49 PM, Jeffrey Tan via lldb-dev > wrote: > > Hi, > > I have got lldb launch working fine on my macbook for sometime. But when I > try the same code on Linux, it failed

Re: [lldb-dev] [3.8 Release] Release status

On Mon, Feb 22, 2016 at 10:48 PM, Hans Wennborg wrote: > I had hoped to tag rc3 today (I feel like I've said this a lot > lately), but it's at least really, really close. I'm waiting for: > > - r261297 - Implement the likely resolution of core issue 253. > Still in