Re: [lldb-dev] Failing LIT-based lldb-mi tests

That't interesting. Where you able to simulate the error seen on the bots by inserting a sleep() unto the debugged program? -- adrian > On Aug 10, 2018, at 5:06 PM, Александр Поляков wrote: > > It seems that lldb-mi in such a situation just hangs: > > build/bin/lldb-mi --synchronous bash > (g

Re: [lldb-dev] Failing LIT-based lldb-mi tests

It seems that lldb-mi in such a situation just hangs: build/bin/lldb-mi --synchronous bash (gdb) -file-exec-and-symbols "bash" ^done (gdb) =library-loaded,id="/bin/bash",target-name="/bin/bash",host-name="/bin/bash",symbols-loaded="0",loaded_addr="-",size="0" -exec-run ^C^C exit It doesn't react

Re: [lldb-dev] Failing LIT-based lldb-mi tests

> On Aug 10, 2018, at 4:50 PM, Александр Поляков wrote: > > One important question: what do you mean talking about "block"? Does it mean > that SBTarget::Launch blocks the process and the user can't continue working > with this process until it stops? Pretty much. The same way as the interac

Re: [lldb-dev] Failing LIT-based lldb-mi tests

One important question: what do you mean talking about "block"? Does it mean that SBTarget::Launch blocks the process and the user can't continue working with this process until it stops? сб, 11 авг. 2018 г. в 2:41, Adrian Prantl : > I was wondering how this worked in the regular SBAPI that we us

Re: [lldb-dev] Failing LIT-based lldb-mi tests

I was wondering how this worked in the regular SBAPI that we use for all the "normal" python-based LLDB tests. The implementation of SBProcess::Continue() for example calls Process::Resume() or Process::ResumeSynchronous() depending on whether synchronous mode is set or not. It's not immediately

Re: [lldb-dev] Failing LIT-based lldb-mi tests

AFAIK, there is no mechanism in lldb-mi to distinguish a command that expects a frame, so we need to modify each command manually. Am I right? If so, I found the Process::WaitForProcessToStop method which we can add to SB API and use in lldb-mi. сб, 11 авг. 2018 г. в 0:50, Adrian Prantl : > [addi

Re: [lldb-dev] Failing LIT-based lldb-mi tests

[adding lldb-dev back to the conversation] > On Aug 10, 2018, at 2:37 PM, Adrian Prantl wrote: > > > >> On Aug 10, 2018, at 2:25 PM, Александр Поляков >> wrote: >> >> I didn't check this yet. lldb-mi already runs LIT test in the --synchronous >> mode and the tests keep failing. >> > > Ye

Re: [lldb-dev] Failing LIT-based lldb-mi tests

> On Aug 10, 2018, at 11:13 AM, Adrian Prantl via lldb-dev > wrote: > > [+lldb-dev, since this affects all bots equally] > > Alexander, it looks like there is a race condition in some of the LIT-based > lldb-mi tests. > > For example, exec-next.test: > > # Test lldb-mi -exec-next command.

[lldb-dev] Failing LIT-based lldb-mi tests

[+lldb-dev, since this affects all bots equally] Alexander, it looks like there is a race condition in some of the LIT-based lldb-mi tests. For example, exec-next.test: # Test lldb-mi -exec-next command. # Check that we have a valid target created via '%lldbmi %t'. # CHECK: ^done -bre

Re: [lldb-dev] Missing Value Formats for wchar_t* and char16_t*

Friendly ping on this? On Fri, Jul 27, 2018 at 11:49 AM Ben Ruthig wrote: > Hi, > > The list of Var Formats supported by > LLDB appears to be missing ones for wchar_t* and char16_t data types. I am > aware that LLDB includes built in summary providers for

Re: [lldb-dev] stable layout bug for imported record decls.

Hi Lang, Alexey, I dug deeper into this and it seems like the issue happens only when a **minimal** import is used. LLDB uses the minimal import. CrossTU static analyzer uses the normal mode. In normal import mode, in `ImportDeclContext` we do import all the methods in the correct order. However,

[lldb-dev] [Bug 38520] New: no pager for help.

https://bugs.llvm.org/show_bug.cgi?id=38520 Bug ID: 38520 Summary: no pager for help. Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P