date:20160707

Re: [lldb-dev] Add support for OCaml native debugging

2016-07-07 Thread Tamas Berghammer via lldb-dev

What type of binaries do you want to commit in?

Generally we don't like putting binaries to the repository because they are
not human readable so it is hard to review/diff them and they will only run
on a single platform and a single architecture while we support a lot of
different configuration.

Tamas

On Wed, Jul 6, 2016 at 3:26 PM E BOUTALEB via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I would like to submit two patches for code review.
> They introduce concrete support for OCaml native debugging, granted that
> you have access to the native compiler with DWARF emission support (see
> https://github.com/ocaml/ocaml/pull/574)
>
> This adds about 2000 lines of code.
> The type system isn't particularly complex here, every value is considered
> as an unsigned integer, and interpretation of the value is left to an
> external debugging layer made in OCaml.
> The language plugin handles function name demangling for breakpoints too.
>
> No tests for now. Is it fine to commit binaries with the patchs?
>
> Elias Boutaleb
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 28455] New: Thread state not in sync with process state

2016-07-07 Thread via lldb-dev

https://llvm.org/bugs/show_bug.cgi?id=28455

Bug ID: 28455
   Summary: Thread state not in sync with process state
   Product: lldb
   Version: 3.8
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: marius.tranda...@ni.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Created attachment 16710
  --> https://llvm.org/bugs/attachment.cgi?id=16710&action=edit
repro code snippet

When the process state is SBProcess::eStateStopped, both SBThread::IsSuspended
and SBThread::IsStopped return false [ thread.m_state is eStateUnloading and
thread.m_resume_state is eStateRunning ]

Is this the intended behavior ?

I used the attached code to reproduce the problem.
The debuggee can be a C/C++ "hello world" app.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 28455] Thread state not in sync with process state

2016-07-07 Thread via lldb-dev

https://llvm.org/bugs/show_bug.cgi?id=28455

lab...@google.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||lab...@google.com
 Resolution|--- |DUPLICATE

--- Comment #1 from lab...@google.com ---
Yes, the IsStopped issue is a known bug. The suspended flag should work, but it
does something else: it reflect whether you have asked the thread not to run
with SBThread.Suspend().

*** This bug has been marked as a duplicate of bug 15824 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB-MI from Eclipse hangs

2016-07-07 Thread via lldb-dev

Thanks Greg for your reply.

Attached below is the GDB trace, please let me know if it helps in any ways.

It would be helpful if you can tell me on how to capture (I am really new
to lldb, sorry for bothering you):
- sample lldb-mi to see what it is doing.
- complete packet log of the traffic between Eclipse and lldb-mi

I am trying with simple "Hello world" c++ program, so libraries should to
be a problem. Also, same remote debugging is working fine if I manually do
it using lldb-mi from command prompt. The hang is happening only when I try
to do it via eclipse.

I am trying via eclipse, because I am looking for some IDE based remote
debugging solution. And Xcode 5 does not support it. Please let me know if
you have any other suggestion.




313,309 2-environment-cd "/Users/admin/Documents/workspace/Hello World C++
Project"

313,314 2^done,path="/Users/admin/Documents/workspace/Hello World C++
Project"

313,315 (gdb)

313,321 3-gdb-set breakpoint pending on

313,322 3^done

313,323 (gdb)

313,327 4-gdb-set detach-on-fork on

313,327 4^done

313,328 (gdb)

313,330 5-enable-pretty-printing

313,388 5^done,supported="0"

313,394 (gdb)

313,404 6-gdb-set python print-stack none

313,404 6^done

313,405 (gdb)

313,407 7-gdb-set print object on

313,408 7^error,msg="The request ''print' error. The option 'object' not
found' failed."

313,409 (gdb)

313,411 8-gdb-set print sevenbit-strings on

313,413 8^error,msg="The request ''print' error. The option
'sevenbit-strings' not found' failed."

313,434 (gdb)

313,436 9-gdb-set host-charset UTF-8

313,436 9^done

313,437 (gdb)

313,439 10-gdb-set target-charset UTF-8

313,440 10^done

313,442 (gdb)

313,446 11-gdb-set target-wide-charset UTF-32

313,447 11^done

313,447 (gdb)

313,449 12-gdb-set target-async off

313,453 12^done

313,453 (gdb)

313,454 13-gdb-set auto-solib-add on

313,455 13^done

313,455 (gdb)

313,464 14-file-exec-and-symbols --thread-group i1
"/Users/admin/Documents/workspace/Hello World C++\

 Project/Debug/Hello World C++ Project"

313,625 14^done

313,626 =library-loaded,id="/Users/admin/Documents/workspace/Hello World
C++ Project/Debug/Hello Wor\

ld C++ Project",target-name="/Users/admin/Documents/workspace/Hello World
C++ Project/Debug/Hello Wo\

rld C++ Project",host-name="/Users/admin/Documents/workspace/Hello World
C++ Project/Debug/Hello Wor\

ld C++ Project",symbols-loaded="0",loaded_addr="-",size="8192"

313,626 (gdb)

313,627 15-target-select remote 192.168.116.141:1234

314,260 15^connected

314,260 =thread-group-started,id="i1",pid="1725"

314,261 =thread-created,id="1",group-id="i1"

314,261 =thread-selected,id="1"

314,261 (gdb)

314,261
=library-loaded,id="/usr/lib/dyld",target-name="/usr/lib/dyld",host-name="/usr/lib/dyld",sym\

bols-loaded="0",loaded_addr="0x7fff65fd2000",size="229376"

314,261 (gdb)

314,261
=library-loaded,id="/usr/lib/libc++.1.dylib",target-name="/usr/lib/libc++.1.dylib",host-name\

="/usr/lib/libc++.1.dylib",symbols-loaded="0",loaded_addr="0x7fff90557000",size="344064"

314,261 (gdb)

314,261
=library-loaded,id="/usr/lib/libSystem.B.dylib",target-name="/usr/lib/libSystem.B.dylib",hos\

t-name="/usr/lib/libSystem.B.dylib",symbols-loaded="0",loaded_addr="0x7fff88a4c000",size="8192"

314,261 (gdb)

314,261
=library-loaded,id="/usr/lib/libc++abi.dylib",target-name="/usr/lib/libc++abi.dylib",host-na\

me="/usr/lib/libc++abi.dylib",symbols-loaded="0",loaded_addr="0x7fff8fb0f000",size="172032"

314,261 (gdb)

314,261
=library-loaded,id="/usr/lib/system/libcache.dylib",target-name="/usr/lib/system/libcache.dy\

lib",host-name="/usr/lib/system/libcache.dylib",symbols-loaded="0",loaded_addr="0x7fff8be07000",\

size="20480"

314,262 (gdb)

314,262
=library-loaded,id="/usr/lib/system/libcommonCrypto.dylib",target-name="/usr/lib/system/libc\

ommonCrypto.dylib",host-name="/usr/lib/system/libcommonCrypto.dylib",symbols-loaded="0",loaded_addr=\

"0x7fff8afba000",size="49152"

314,262 (gdb)

314,262
=library-loaded,id="/usr/lib/system/libcompiler_rt.dylib",target-name="/usr/lib/system/libco\

mpiler_rt.dylib",host-name="/usr/lib/system/libcompiler_rt.dylib",symbols-loaded="0",loaded_addr="0x\

7fff8c6ed000",size="32768"

314,262 (gdb)

314,262
=library-loaded,id="/usr/lib/system/libcopyfile.dylib",target-name="/usr/lib/system/libcopyf\

ile.dylib",host-name="/usr/lib/system/libcopyfile.dylib",symbols-loaded="0",loaded_addr="0x7fff8\

c6f5000",size="36864"

314,262 (gdb)

314,262
=library-loaded,id="/usr/lib/system/libcorecrypto.dylib",target-name="/usr/lib/system/libcor\

ecrypto.dylib",host-name="/usr/lib/system/libcorecrypto.dylib",symbols-loaded="0",loaded_addr="0x000\

07fff87435000",size="491520"

314,262 (gdb)

314,262
=library-loaded,id="/usr/lib/system/libdispatch.dylib",target-name="/usr/lib/system/libdispa\

tch.dylib",host-name="/usr/lib/sy

Re: [lldb-dev] Remote debugging - unix socket and/or specific port

2016-07-07 Thread Adrien Duermael via lldb-dev

Hi Pavel, 

Thanks for your answer! At least I know it’s not supposed to work as is. 
I’ll see if I can do something similar to what you guys did for Android 
platforms. 

Thanks again!

Cheers, 

- Adrien Duermael

> On Jun 29, 2016, at 5:07 AM, Pavel Labath  wrote:
> 
> Hi Adrien,
> 
> I think your diagnosis is correct here. LLDB does indeed create an additional 
> connection to the gdb-server instance which is started by the platform 
> instance when you start debugging. In case of android platforms we already 
> include code to forward this port automatically, but there is no such thing 
> for linux -- we just expect the server to be reachable.
> 
> Unfortunately, there is no way to control this behavior at the moment. I 
> suppose you could unblock all ports on the container, but make sure that they 
> are only reachable from the host (I know that's not ideal).
> 
> cheers,
> pl
> 
> 
> On 22 June 2016 at 19:18, Adrien Duermael via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> Hi, 
> 
> I’ve been trying to run lldb-server from within a linux container lately. 
> 
> When I try to attach from outside the container using lldb command, most 
> steps are successful but I can’t launch the process:
> 
> platform select remote-linux 👍
> platform connect connect://IP:PORT <> 👍
> target create main 👍
> process launch ❌
> 
> My guess is that the container only exposes the control port, the one I’m 
> listening to with lldb-server p --listen *:PORT.
> And it seems that ports are dynamically allocated to then handle process 
> debugging. 
> 
> I don’t want my container to expose too many ports, as I usually have in fact 
> only one debuggable process running inside.
> (I tried, I can launch my process if the container exposes all ports)
> 
> Is there a way to set a range for these dynamically allocated ports using 
> lldb-server?
> 
> I can’t find it in the docs, and help command can’t help me either:
> Usage:
>   lldb-server p [--log-file log-file-name] [--log-channels log-channel-list] 
> [--port-file port-file-path] --server --listen port
> 
> Also, is there an option to use unix sockets instead of ports?
> 
> Thanks for your help!
> 
> - Adrien Duermael
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
> 
> 
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Add support for OCaml native debugging

2016-07-07 Thread Zachary Turner via lldb-dev

I don't like the idea of not having tests. Promising tests and actually
delivering on them are two entirely different things. And without them, we
just end up with broken code and nobody to maintain it
On Thu, Jul 7, 2016 at 6:23 AM Tamas Berghammer via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> What type of binaries do you want to commit in?
>
> Generally we don't like putting binaries to the repository because they
> are not human readable so it is hard to review/diff them and they will only
> run on a single platform and a single architecture while we support a lot
> of different configuration.
>
> Tamas
>
> On Wed, Jul 6, 2016 at 3:26 PM E BOUTALEB via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> I would like to submit two patches for code review.
>> They introduce concrete support for OCaml native debugging, granted that
>> you have access to the native compiler with DWARF emission support (see
>> https://github.com/ocaml/ocaml/pull/574)
>>
>> This adds about 2000 lines of code.
>> The type system isn't particularly complex here, every value is
>> considered as an unsigned integer, and interpretation of the value is left
>> to an external debugging layer made in OCaml.
>> The language plugin handles function name demangling for breakpoints too.
>>
>> No tests for now. Is it fine to commit binaries with the patchs?
>>
>> Elias Boutaleb
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Add support for OCaml native debugging

2016-07-07 Thread E BOUTALEB via lldb-dev

I understand your concern.
I guess it could be possible to create a 
conditional test exercised on a particular condition (like the presence 
of the native compiler), and skipped otherwise.
Is it possible for 
new files to trigger regressions? Most of the changes concern the 
language plugins, AST context and DWARF parser.

Elias

From: ztur...@google.com
Date: Thu, 7 Jul 2016 16:05:06 +
Subject: Re: [lldb-dev] Add support for OCaml native debugging
To: tbergham...@google.com; e.bouta...@hotmail.fr; lldb-dev@lists.llvm.org

I don't like the idea of not having tests.  Promising tests and actually 
delivering on them are two entirely different things.  And without them, we 
just end up with broken code and nobody to maintain it
On Thu, Jul 7, 2016 at 6:23 AM Tamas Berghammer via lldb-dev 
 wrote:
What type of binaries do you want to commit in?
Generally we don't like putting binaries to the repository because they are not 
human readable so it is hard to review/diff them and they will only run on a 
single platform and a single architecture while we support a lot of different 
configuration.
Tamas
On Wed, Jul 6, 2016 at 3:26 PM E BOUTALEB via lldb-dev 
 wrote:



I would like to submit two patches for code review.
They introduce concrete support for OCaml native debugging, granted that you 
have access to the native compiler with DWARF emission support (see 
https://github.com/ocaml/ocaml/pull/574)

This adds about 2000 lines of code. 
The type system isn't particularly complex here, every value is considered as 
an unsigned integer, and interpretation of the value is left to an external 
debugging layer made in OCaml.
The language plugin handles function name demangling for breakpoints too.

No tests for now. Is it fine to commit binaries with the patchs?

Elias Boutaleb
  
___

lldb-dev mailing list

lldb-dev@lists.llvm.org

http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


___

lldb-dev mailing list

lldb-dev@lists.llvm.org

http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

  ___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB-MI from Eclipse hangs

2016-07-07 Thread Greg Clayton via lldb-dev

It looks like we continue and then ask fore thread groups? I am not sure on the 
rules of MI. Can you ask another question before receiving a response? If we 
say command 18 is "-exec-continue --thread-group i1", can you send command 19 
without receiving a response?

314,372 18-exec-continue --thread-group i1
319,380 19-list-thread-groups

I would sample the lldb-mi when it is deadlocked:

% sample lldb-mi

Then attach the sample output to your response.

> On Jul 7, 2016, at 8:53 AM, dipt...@gmail.com wrote:
> 
> 
> 313,309 2-environment-cd "/Users/admin/Documents/workspace/Hello World C++ 
> Project"
> 313,314 2^done,path="/Users/admin/Documents/workspace/Hello World C++ Project"
> 313,315 (gdb)
> 313,321 3-gdb-set breakpoint pending on
> 313,322 3^done
> 313,323 (gdb)
> 313,327 4-gdb-set detach-on-fork on
> 313,327 4^done
> 313,328 (gdb)
> 313,330 5-enable-pretty-printing
> 313,388 5^done,supported="0"
> 313,394 (gdb)
> 313,404 6-gdb-set python print-stack none
> 313,404 6^done
> 313,405 (gdb)
> 313,407 7-gdb-set print object on
> 313,408 7^error,msg="The request ''print' error. The option 'object' not 
> found' failed."
> 313,409 (gdb)
> 313,411 8-gdb-set print sevenbit-strings on
> 313,413 8^error,msg="The request ''print' error. The option 
> 'sevenbit-strings' not found' failed."
> 313,434 (gdb)
> 313,436 9-gdb-set host-charset UTF-8
> 313,436 9^done
> 313,437 (gdb)
> 313,439 10-gdb-set target-charset UTF-8
> 313,440 10^done
> 313,442 (gdb)
> 313,446 11-gdb-set target-wide-charset UTF-32
> 313,447 11^done
> 313,447 (gdb)
> 313,449 12-gdb-set target-async off
> 313,453 12^done
> 313,453 (gdb)
> 313,454 13-gdb-set auto-solib-add on
> 313,455 13^done
> 313,455 (gdb)
> 313,464 14-file-exec-and-symbols --thread-group i1 
> "/Users/admin/Documents/workspace/Hello World C++\
>  Project/Debug/Hello World C++ Project"
> 313,625 14^done
> 313,626 =library-loaded,id="/Users/admin/Documents/workspace/Hello World C++ 
> Project/Debug/Hello Wor\
> ld C++ Project",target-name="/Users/admin/Documents/workspace/Hello World C++ 
> Project/Debug/Hello Wo\
> rld C++ Project",host-name="/Users/admin/Documents/workspace/Hello World C++ 
> Project/Debug/Hello Wor\
> ld C++ Project",symbols-loaded="0",loaded_addr="-",size="8192"
> 313,626 (gdb)
> 313,627 15-target-select remote 192.168.116.141:1234
> 314,260 15^connected
> 314,260 =thread-group-started,id="i1",pid="1725"
> 314,261 =thread-created,id="1",group-id="i1"
> 314,261 =thread-selected,id="1"
> 314,261 (gdb)
> 314,261 
> =library-loaded,id="/usr/lib/dyld",target-name="/usr/lib/dyld",host-name="/usr/lib/dyld",sym\
> bols-loaded="0",loaded_addr="0x7fff65fd2000",size="229376"
> 314,261 (gdb)
> 314,261 
> =library-loaded,id="/usr/lib/libc++.1.dylib",target-name="/usr/lib/libc++.1.dylib",host-name\
> ="/usr/lib/libc++.1.dylib",symbols-loaded="0",loaded_addr="0x7fff90557000",size="344064"
> 314,261 (gdb)
> 314,261 
> =library-loaded,id="/usr/lib/libSystem.B.dylib",target-name="/usr/lib/libSystem.B.dylib",hos\
> t-name="/usr/lib/libSystem.B.dylib",symbols-loaded="0",loaded_addr="0x7fff88a4c000",size="8192"
> 314,261 (gdb)
> 314,261 
> =library-loaded,id="/usr/lib/libc++abi.dylib",target-name="/usr/lib/libc++abi.dylib",host-na\
> me="/usr/lib/libc++abi.dylib",symbols-loaded="0",loaded_addr="0x7fff8fb0f000",size="172032"
> 314,261 (gdb)
> 314,261 
> =library-loaded,id="/usr/lib/system/libcache.dylib",target-name="/usr/lib/system/libcache.dy\
> lib",host-name="/usr/lib/system/libcache.dylib",symbols-loaded="0",loaded_addr="0x7fff8be07000",\
> size="20480"
> 314,262 (gdb)
> 314,262 
> =library-loaded,id="/usr/lib/system/libcommonCrypto.dylib",target-name="/usr/lib/system/libc\
> ommonCrypto.dylib",host-name="/usr/lib/system/libcommonCrypto.dylib",symbols-loaded="0",loaded_addr=\
> "0x7fff8afba000",size="49152"
> 314,262 (gdb)
> 314,262 
> =library-loaded,id="/usr/lib/system/libcompiler_rt.dylib",target-name="/usr/lib/system/libco\
> mpiler_rt.dylib",host-name="/usr/lib/system/libcompiler_rt.dylib",symbols-loaded="0",loaded_addr="0x\
> 7fff8c6ed000",size="32768"
> 314,262 (gdb)
> 314,262 
> =library-loaded,id="/usr/lib/system/libcopyfile.dylib",target-name="/usr/lib/system/libcopyf\
> ile.dylib",host-name="/usr/lib/system/libcopyfile.dylib",symbols-loaded="0",loaded_addr="0x7fff8\
> c6f5000",size="36864"
> 314,262 (gdb)
> 314,262 
> =library-loaded,id="/usr/lib/system/libcorecrypto.dylib",target-name="/usr/lib/system/libcor\
> ecrypto.dylib",host-name="/usr/lib/system/libcorecrypto.dylib",symbols-loaded="0",loaded_addr="0x000\
> 07fff87435000",size="491520"
> 314,262 (gdb)
> 314,262 
> =library-loaded,id="/usr/lib/system/libdispatch.dylib",target-name="/usr/lib/system/libdispa\
> tch.dylib",host-name="/usr/lib/system/libdispatch.dylib",symbols-loaded="0",loaded_addr="0x7fff8\
> de7",size="188416"
>

Re: [lldb-dev] LLDB-MI from Eclipse hangs

2016-07-07 Thread Greg Clayton via lldb-dev

Actually you should have seen a ^running as a response from -exec-continue:

-exec-continue
^running
(gdb)

But we don't see that here.

Also, -exec-continue doesn't believe it takes any arguments in the lldb-mi. 
Check the tools/lldb-mi/MICmdCmdExec.cpp source file in the LLDB sources. Note 
that is says "Args:None.". Not sure what lldb-mi does if arguments are 
passed to a command that doesn't believe it takes any arguments...

//++ 

// Details: CMICmdCmdExecContinue constructor.
// Type:Method.
// Args:None.
// Return:  None.
// Throws:  None.
//--
CMICmdCmdExecContinue::CMICmdCmdExecContinue()
{
// Command factory matches this name with that received from the stdin 
stream
m_strMiCmd = "exec-continue";

// Required by the CMICmdFactory when registering *this command
m_pSelfCreatorFn = &CMICmdCmdExecContinue::CreateSelf;
}

//++ 

// Details: CMICmdCmdExecContinue destructor.
// Type:Overrideable.
// Args:None.
// Return:  None.
// Throws:  None.
//--
CMICmdCmdExecContinue::~CMICmdCmdExecContinue()
{
}

//++ 

// Details: The invoker requires this function. The command does work in this 
function.
//  The command is likely to communicate with the LLDB SBDebugger in 
here.
// Type:Overridden.
// Args:None.
// Return:  MIstatus::success - Functional succeeded.
//  MIstatus::failure - Functional failed.
// Throws:  None.
//--
bool
CMICmdCmdExecContinue::Execute()
{
const char *pCmd = "continue";
CMICmnLLDBDebugSessionInfo 
&rSessionInfo(CMICmnLLDBDebugSessionInfo::Instance());
const lldb::ReturnStatus rtn = 
rSessionInfo.GetDebugger().GetCommandInterpreter().HandleCommand(pCmd, 
m_lldbResult);
MIunused(rtn);

if (m_lldbResult.GetErrorSize() == 0)
{
// CODETAG_DEBUG_SESSION_RUNNING_PROG_RECEIVED_SIGINT_PAUSE_PROGRAM
if (!CMIDriver::Instance().SetDriverStateRunningDebugging())
{
const CMIUtilString 
&rErrMsg(CMIDriver::Instance().GetErrorDescription());

SetError(CMIUtilString::Format(MIRSRC(IDS_CMD_ERR_SET_NEW_DRIVER_STATE), 
m_cmdData.strMiCmd.c_str(), rErrMsg.c_str()));
return MIstatus::failure;
}
}
else
{
// ToDo: Re-evaluate if this is required when application near finished 
as this is parsing LLDB error message
// which seems a hack and is code brittle
const char *pLldbErr = m_lldbResult.GetError();
const CMIUtilString 
strLldbMsg(CMIUtilString(pLldbErr).StripCREndOfLine());
if (strLldbMsg == "error: Process must be launched.")
{
CMIDriver::Instance().SetExitApplicationFlag(true);
}
}

return MIstatus::success;
}

//++ 

// Details: The invoker requires this function. The command prepares a MI 
Record Result
//  for the work carried out in the Execute().
// Type:Overridden.
// Args:None.
// Return:  MIstatus::success - Functional succeeded.
//  MIstatus::failure - Functional failed.
// Throws:  None.
//--
bool
CMICmdCmdExecContinue::Acknowledge()
{
if (m_lldbResult.GetErrorSize() > 0)
{
const CMICmnMIValueConst miValueConst(m_lldbResult.GetError());
const CMICmnMIValueResult miValueResult("message", miValueConst);
const CMICmnMIResultRecord miRecordResult(m_cmdData.strMiCmdToken, 
CMICmnMIResultRecord::eResultClass_Error, miValueResult);
m_miResultRecord = miRecordResult;
}
else
{
const CMICmnMIResultRecord miRecordResult(m_cmdData.strMiCmdToken, 
CMICmnMIResultRecord::eResultClass_Running);
m_miResultRecord = miRecordResult;
}

return MIstatus::success;
}

//++ 

// Details: Required by the CMICmdFactory when registering *this command. The 
factory
//  calls this function to create an instance of *this command.
// Type:Static method.
// Args:None.
// Return:  CMICmdBase * - Pointer to a new command.
// Throws:  None.
//--
CMICmdBase *
CMICmdCmdExecContinue::CreateSelf()
{
return new CMICmdCmdExecContinue();
}

> On Jul 7, 2016, at 5:19 PM, Greg Clayton  wrote:
> 
> It looks like we continue and then ask fore thread groups? I am not sure on 
> the rules of MI. Can you ask another question before receiving a response? If 
> we say command 18 is "-exec-continue --thread-group i1", can you send command 
> 19 without receiving a response?
> 
> 314,372 18-exec-continue --thread-group i1
> 319,380 19-list-thread-groups
> 
> I would sample the lldb-mi when it is deadlocked:
> 
> % sample lldb-mi
> 
> Then attach the sample output to your res

Re: [lldb-dev] [llvm-dev] [llvm-foundation] Sequential ID Git hook

2016-07-07 Thread Tim Northover via lldb-dev

On 7 July 2016 at 17:56, Chris Matthews via llvm-dev
 wrote:
> With both llvmlab and LNT, once you get to a range of IDs, it is needs to be
> easy to find out what commits or commit range those IDs map to.

Making no comment on how easy or hard it will actually be, doesn't it
just have to be possible? We're talking about some python function
someone will write once and forget about pretty much forever
afterwards, aren't we?

Tim.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [llvm-foundation] Sequential ID Git hook

2016-07-07 Thread Robinson, Paul via lldb-dev

I could see wanting to compare data from master and a release branch.  If that 
means sequential IDs need to work across branches, then we're back to needing a 
fancier solution than 'rev-list –count'.
--paulr

From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of Chris 
Matthews via llvm-dev
Sent: Thursday, July 07, 2016 5:56 PM
To: Renato Golin via llvm-foundation; Renato Golin; Mehdi Amini
Cc: LLVM Dev; llvm-foundat...@lists.llvm.org; Clang Dev; LLDB Dev
Subject: Re: [llvm-dev] [llvm-foundation] Sequential ID Git hook

Sequential IDs are important for LNT and llvmlab bisection tool.

LNT uses the “order” to capture the measured software changes.  LNT does make 
the assumption that orders are unique, so if a ID was the same on two branches, 
LNT would assume that is the same change.  If you never want to compare data 
between branches, storing each branch in a different database solves that 
problem, but sometimes you do want to directly compare runs in two branches.

With both llvmlab and LNT, once you get to a range of IDs, it is needs to be 
easy to find out what commits or commit range those IDs map to.  When given 
regression between 123 and 225, I need the list of commits, and I don’t want to 
log grep for those numbers. Ideally it should also easy for those tools to link 
to a revision on a webUI like viewvc.

On July 5, 2016 at 4:04:05 PM, Renato Golin via llvm-foundation 
(llvm-foundat...@lists.llvm.org) wrote:

On 5 Jul 2016 10:45 p.m., "Mehdi Amini" 
mailto:mehdi.am...@apple.com>> wrote:
>
>
> > On Jul 5, 2016, at 3:44 AM, Renato Golin via llvm-dev 
> > mailto:llvm-...@lists.llvm.org>> wrote:
> >
> > Quick re-cap.
> >
> > After a few rounds, not only the "external server" proposal got
> > obliterated as totally unnecessary, but the idea that we may even need
> > a hook at all is now challenged.
>
> This is not clear to me.
> How is the umbrella repository updated?

Sorry, I meant no hooks for updating sequential ids. We still need a hook to 
update the umbrella project.

Cheers,
Renato
___
llvm-foundation mailing list
llvm-foundat...@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-foundation
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Add support for OCaml native debugging

[lldb-dev] [Bug 28455] New: Thread state not in sync with process state

[lldb-dev] [Bug 28455] Thread state not in sync with process state

Re: [lldb-dev] LLDB-MI from Eclipse hangs

Re: [lldb-dev] Remote debugging - unix socket and/or specific port

Re: [lldb-dev] Add support for OCaml native debugging

Re: [lldb-dev] Add support for OCaml native debugging

Re: [lldb-dev] LLDB-MI from Eclipse hangs

Re: [lldb-dev] LLDB-MI from Eclipse hangs

Re: [lldb-dev] [llvm-dev] [llvm-foundation] Sequential ID Git hook

Re: [lldb-dev] [llvm-dev] [llvm-foundation] Sequential ID Git hook

11 matches

Site Navigation

Mail list logo

Footer information