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
Prior
https://llvm.org/bugs/show_bug.cgi?id=26289
Luke Drummond changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://llvm.org/bugs/show_bug.cgi?id=26289
Luke Drummond changed:
What|Removed |Added
Resolution|FIXED |INVALID
--
You are receiving this mail because
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 post-commit review.
>
> - D175
Ok, sounds like you first need to see if "-gdb-set solib-search-path" is hooked
up to "target modules search-paths add". If not, hook it up. Then we probably
need to add a function to Platform.cpp that can use a target's module search
paths to help find an executable. This can probably be a virt
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 b
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
t
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 main
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 c
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 understandin
> 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 issue in general (Pavel isn't
> sharing my opi
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 straightforw
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 will
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 al
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 waiting for:
>>
>> - r261297 - Implement the li
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 to emit any stopping event
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 he
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 wrote:
> If the li
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 expr
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
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 wo
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
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 wrote:
>
> 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
> platfor
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
MemorySanitiz
This is a very useful read! I am also building a IDE debugger using lldb, and I
found the initial attach/launch API and eventing system has a lot quirks. After
getting to stopped state, querying info is relative trivial. Thanks again.
Sent from my iPad
> On Feb 23, 2016, at 2:40 PM, Greg Clayto
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 wrote:
>>
>> I am not sure. From the out
26 matches
Mail list logo
