> It might be interesting to consider how this is addressed by the
> ExternalASTSource interface. There, we have separate "import the lexical
> contents of this AST node (including populating the lexical declarations list
> with all members, in the right order)", "import the lookup results for t
It seems that the real problem is that sometimes lldb-mi can't launch a
process:
build/bin/lldb-mi --synchronous a.out <
llvm/tools/lldb/lit/tools/lldb-mi/exec/exec-step-instruction.test
(gdb)
-file-exec-and-symbols "a.out"
^done
(gdb)
^done
(gdb)
=library-loaded,id="/home/alexander/workspace/gsoc
> On Aug 14, 2018, at 12:11 PM, Александр Поляков
> wrote:
>
> It seems that the real problem is that sometimes lldb-mi can't launch a
> process:
>
> build/bin/lldb-mi --synchronous a.out <
> llvm/tools/lldb/lit/tools/lldb-mi/exec/exec-step-instruction.test
> (gdb)
> -file-exec-and-symbols
After long-long debugging I found out that lldb-mi can't successfully
launch a process since sometimes it isn't connected with something(I don't
know what is it).
I found out that it fails after `if (IsConnected())` from
`GDBRemoteCommunication::SendPacketNoLock(llvm::StringRef payload)`.
Do you h
> On Aug 14, 2018, at 2:13 PM, Александр Поляков wrote:
>
> After long-long debugging I found out that lldb-mi can't successfully launch
> a process since sometimes it isn't connected with something(I don't know what
> is it).
> I found out that it fails after `if (IsConnected())` from
> `GD
CMICmdCmdExecRun::Execute has this line:
lldb::SBProcess process = rSessionInfo.GetTarget().Launch(launchInfo, error);
That should do the same thing as the “process launch” command, which will
launch lldb-server (linux, bsd, etc) or debugserver (mac), connect to it, and
send the A packe
Here is what I got from gdb-remote packet log:
(gdb)
lldb-mi < 1> send packet: +
lldb-mi history[1] tid=0x784a < 1> send packet: +
lldb-mi < 19> send packet: $QStartNoAckMode#b0
lldb-mi < 1> read packet: +
lldb-mi < 6> read packet: $OK#9a
lldb-
> On Aug 14, 2018, at 2:43 PM, Александр Поляков wrote:
>
> Here is what I got from gdb-remote packet log:
>
> (gdb)
> lldb-mi < 1> send packet: +
> lldb-mi history[1] tid=0x784a < 1> send packet: +
> lldb-mi < 19> send packet: $QStartNoAckMode#b0
> lldb-mi
Yes, it is. Here is the gdb-remote process log:
(gdb)
-file-exec-and-symbols "a.out"
^done
(gdb)
^done
(gdb)
=library-loaded,id="/home/alexander/workspace/gsoc/a.out",target-name="/home/alexander/workspace/gsoc/a.out",host-name="/home/alexander/workspace/gsoc/a.out",symbols-loaded="0",loaded_addr=
That looks normal, up until the A packet failure. I’m building ToT lldb-mi
right now on Ubuntu 14.04. What OS are you running on?
From: Александр Поляков
Sent: Tuesday, August 14, 2018 4:56 PM
To: Adrian Prantl
Cc: Ted Woodward ; LLDB
Subject: Re: [lldb-dev] Failing LIT-based lldb-mi tests
I'm running Ubuntu 16.04. The lldb-mi behaves in such a way randomly, the
only thing that in my opinion can lead to this error is high busyness of
the machine that runs debug session, but I'm not sure.
On Wed, Aug 15, 2018 at 12:59 AM wrote:
> That looks normal, up until the A packet failure. I’
Yes, the communications back and forth indicate that lldb-server is running and
lldb-mi is connected to it.
My run was successful. You mentioned load on the machine; do you see any failed
runs from lldb? Both lldb and lldb-mi make the same call (Target::Launch) to
start the process.
My l
LLDB fails with the same symptoms:
lldb < 1> send packet: +
lldb history[1] tid=0x0c09 < 1> send packet: +
lldb < 19> send packet: $QStartNoAckMode#b0
lldb < 1> read packet: +
lldb < 6> read packet: $OK#9a
lldb < 1>
Hello,
I'd like to make FileCheck available within lldb inline tests, in addition to
existing helpers like 'runCmd' and 'expect'.
My motivation is that several tests I'm working on can't be made as rigorous as
they need to be without FileCheck-style checks. In particular, the 'matching',
'subs
I’ve thought about this in the past but the conclusion I came to is that
lldbinline tests are actually just filecheck tests in disguise. Why do we
need both? I’d rather delete the lldbinline infrastructure entirely and
make a new lit TestFormat that basically does what lldbinline already does
On Tu
I'd argue against this approach because it's exactly why the lit tests don't
run against the lldb driver -- they're hardcoding the output of the lldb driver
command into the testsuite and these will eventually make it much more
difficult to change and improve the driver as we've accumulated this
Hi Gábor, Richard,
Hi Richard, maybe my understanding is not correct, but I believe the
> situation is somewhat twisted and reversed...
Is this relationship recursive? (Should it be?) I.e. When ClangASTSource
uses ASTImporter to minimally import a Decl, should that Decl have another
ExternalASTS
It'd be easy to update FileCheck tests when changing the debugger (this happens
all the time in clang/swift). OTOH, the verbosity of the python API means that
fewer tests get written. I see a real need to make expressive tests easier to
write.
vedant
> On Aug 14, 2018, at 5:38 PM, Jason Molend
> On Aug 14, 2018, at 5:34 PM, Zachary Turner wrote:
>
> I’ve thought about this in the past but the conclusion I came to is that
> lldbinline tests are actually just filecheck tests in disguise. Why do we
> need both? I’d rather delete the lldbinline infrastructure entirely and make
> a new
On Tue, Aug 14, 2018 at 5:56 PM Vedant Kumar wrote:
>
>
> On Aug 14, 2018, at 5:34 PM, Zachary Turner wrote:
>
> I’ve thought about this in the past but the conclusion I came to is that
> lldbinline tests are actually just filecheck tests in disguise. Why do we
> need both? I’d rather delete the
It's more verbose, and it does mean test writers need to learn the public API,
but it's also much more stable and debuggable in the future. It's a higher up
front cost but we're paid back in being able to develop lldb more quickly in
the future, where our published API behaviors are being teste
Having bugs also makes the debugger harder to innovate in the future
because it’s, not having tests leads to having bugs, and sb api tests leads
to not having tests. At the end of the day, it doesn’t matter how stable
the tests are if there arent enough of them. There should be about 10x-20x
as man
> On Aug 14, 2018, at 6:39 PM, Zachary Turner wrote:
>
> Having bugs also makes the debugger harder to innovate in the future because
> it’s, not having tests leads to having bugs, and sb api tests leads to not
> having tests. At the end of the day, it doesn’t matter how stable the tests
> a
On Tue, Aug 14, 2018 at 6:58 PM Jason Molenda wrote:
>
>
> > On Aug 14, 2018, at 6:39 PM, Zachary Turner wrote:
> >
> > Having bugs also makes the debugger harder to innovate in the future
> because it’s, not having tests leads to having bugs, and sb api tests leads
> to not having te
>
> Yes, l
24 matches
Mail list logo
