Re: [lldb-dev] Question about -break-insert in lldb-mi

[Jim Ingham via lldb-dev]

That is my understanding of what the -f flag is supposed to do.  It doesn't 
take an argument, it just directs gdb to do "future-break" rather than "break". 
 The lldb MI should probably just parse & discard it.

Jim


> On Jul 11, 2016, at 1:59 PM, Pierson Lee (PIE)  
> wrote:
> 
> So the instance I run into the error is setting a conditional breakpoint:
> 
> -break-insert -f -c "x==0" main.cpp:13
> 
> And I get: 
> 
> MI: Error: Command Args. Validation failed. Args missing additional 
> information: f
> ^error,msg="Command 'break-insert'. Command Args. Validation failed. Args 
> missing additional information: f"
> 
> It seems in the tests/examples, -f is the last parameter and the 
> function/code location happens after the -f. 
> 
> From my understanding of the MI Command, the -f is a flag that tells it the 
> breakpoint is to be set as pending if the debugger cannot determine the 
> location of the breakpoint. The optional "parameter" doesn't seem to be used. 
> 
> Does this seem like a bug or am I misunderstanding what the -f flag does on 
> -break-insert ?
> 
> Thanks
> Pierson 
> 
> -Original Message-
> From: Ted Woodward [mailto:ted.woodw...@codeaurora.org] 
> Sent: Monday, July 11, 2016 1:13 PM
> To: Pierson Lee (PIE) ; jing...@apple.com; 'LLDB' 
> 
> Subject: RE: [lldb-dev] Question about -break-insert in lldb-mi
> 
> This is what Eclipse does when setting a breakpoint at main on a Hexagon 
> target, before -exec-run:
> 
> TX:21-break-insert -t -f main
> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
> 
> 
> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Pierson 
> Lee (PIE) via lldb-dev
> Sent: Monday, July 11, 2016 1:33 PM
> To: jing...@apple.com
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Question about -break-insert in lldb-mi
> 
> If I don't specify the -f flag (with some random parameter), then a pending 
> breakpoint is not created and the initial binding fails. But if I specify the 
> -f with the random parameter, then it will bind when the library is loaded. 
> This is the behavior I see on gdb also, but sans the random parameter. I 
> looked at the source code and can't figure out what it expects the parameter 
> to be and what it does with the value. 
> 
> -Original Message-
> From: jing...@apple.com [mailto:jing...@apple.com] 
> Sent: Friday, July 8, 2016 7:03 PM
> To: Pierson Lee (PIE) 
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Question about -break-insert in lldb-mi
> 
> 
> gdb used to try to find a symbol matching the breakpoint specification and if 
> it didn't find one immediately, it would raise an error.  If you didn't want 
> this behavior (in a world with many shared libraries you seldom did) then you 
> could set a "future-break" which is what the -f flag turns on.  This was 
> better though a bit bogus, because it would set the breakpoint the FIRST time 
> it took, then never look again.
> 
> But this was quite a while ago, and I think gdb's gotten better about 
> organizing breakpoints.  But I haven't used a modern gdb for a while, so I'm 
> not sure how it works now-a-days.
> 
> Anyway, lldb's breakpoints don't work that way.  They stay active till you 
> delete them, and keep searching for new matches every time a shared library 
> is loaded.  You could make them emulate the gdb behavior by judiciously 
> deleting & duplicating breakpoints from the original specification, but 
> there's no way to get the native lldb breakpoints to do so (nor should there 
> be IMHO...)
> 
> So if you are using the lldb-mi, there's no reason to bother with the -f 
> flag.  But also lldb-mi should probably just ignore this flag.
> 
> Jim
> 
> 
>> On Jul 8, 2016, at 5:58 PM, Pierson Lee (PIE) via lldb-dev 
>>  wrote:
>> 
>> Hi,
>> 
>> I’m trying to use -break-insert and the -f flag for it. 
>> 
>> I noticed in MICmdCmdBreak.cpp , in CmICmdCmdBreakInsert::ParseArgs() that 
>> the -f has a required parameter.
>> 
>>m_setCmdArgs.Add(new 
>> CMICmdArgValOptionShort(m_constStrArgNamedPendinfBrkPt, false, true,
>>   
>> CMICmdArgValListBase::eArgValType_StringQuotedNumberPath, 1));
>> 
>> 
>> Based on the GDB MI documentation (at 
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fsourceware.org%2fgdb%2fonlinedocs%2fgdb%2fGDB_002fMI-Breakpoint-Commands.html%23GDB_002fMI-Breakpoint-Commands=01%7c01%7cPierson.Lee%40microsoft.com%7c2f7fe625424341c8101908d3a79d5c33%7c72f988bf86f141af91ab2d7cd011db47%7c1=vA0kav9epp3zRa4QivQ9wmimjEHYiJ0AiQfJcGKdzEs%3d)
>>  for -break-insert shows:
>> 
>> ‘-f’
>> If location cannot be parsed (for example if it refers to unknown files or 
>> functions), create a pending 

Re: [lldb-dev] Question about -break-insert in lldb-mi

[Pierson Lee (PIE) via lldb-dev]

So the instance I run into the error is setting a conditional breakpoint:

-break-insert -f -c "x==0" main.cpp:13

And I get: 

MI: Error: Command Args. Validation failed. Args missing additional 
information: f
^error,msg="Command 'break-insert'. Command Args. Validation failed. Args 
missing additional information: f"

It seems in the tests/examples, -f is the last parameter and the function/code 
location happens after the -f. 

From my understanding of the MI Command, the -f is a flag that tells it the 
breakpoint is to be set as pending if the debugger cannot determine the 
location of the breakpoint. The optional "parameter" doesn't seem to be used. 

Does this seem like a bug or am I misunderstanding what the -f flag does on 
-break-insert ?

Thanks
Pierson 

-Original Message-
From: Ted Woodward [mailto:ted.woodw...@codeaurora.org] 
Sent: Monday, July 11, 2016 1:13 PM
To: Pierson Lee (PIE) ; jing...@apple.com; 'LLDB' 

Subject: RE: [lldb-dev] Question about -break-insert in lldb-mi

This is what Eclipse does when setting a breakpoint at main on a Hexagon 
target, before -exec-run:

TX:21-break-insert -t -f main

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


-Original Message-
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Pierson 
Lee (PIE) via lldb-dev
Sent: Monday, July 11, 2016 1:33 PM
To: jing...@apple.com
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Question about -break-insert in lldb-mi

If I don't specify the -f flag (with some random parameter), then a pending 
breakpoint is not created and the initial binding fails. But if I specify the 
-f with the random parameter, then it will bind when the library is loaded. 
This is the behavior I see on gdb also, but sans the random parameter. I looked 
at the source code and can't figure out what it expects the parameter to be and 
what it does with the value. 

-Original Message-
From: jing...@apple.com [mailto:jing...@apple.com] 
Sent: Friday, July 8, 2016 7:03 PM
To: Pierson Lee (PIE) 
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Question about -break-insert in lldb-mi


gdb used to try to find a symbol matching the breakpoint specification and if 
it didn't find one immediately, it would raise an error.  If you didn't want 
this behavior (in a world with many shared libraries you seldom did) then you 
could set a "future-break" which is what the -f flag turns on.  This was better 
though a bit bogus, because it would set the breakpoint the FIRST time it took, 
then never look again.

But this was quite a while ago, and I think gdb's gotten better about 
organizing breakpoints.  But I haven't used a modern gdb for a while, so I'm 
not sure how it works now-a-days.

Anyway, lldb's breakpoints don't work that way.  They stay active till you 
delete them, and keep searching for new matches every time a shared library is 
loaded.  You could make them emulate the gdb behavior by judiciously deleting & 
duplicating breakpoints from the original specification, but there's no way to 
get the native lldb breakpoints to do so (nor should there be IMHO...)

So if you are using the lldb-mi, there's no reason to bother with the -f flag.  
But also lldb-mi should probably just ignore this flag.

Jim
 

> On Jul 8, 2016, at 5:58 PM, Pierson Lee (PIE) via lldb-dev 
>  wrote:
> 
> Hi,
>  
> I’m trying to use -break-insert and the -f flag for it. 
>  
> I noticed in MICmdCmdBreak.cpp , in CmICmdCmdBreakInsert::ParseArgs() that 
> the -f has a required parameter.
>  
> m_setCmdArgs.Add(new 
> CMICmdArgValOptionShort(m_constStrArgNamedPendinfBrkPt, false, true,
>
> CMICmdArgValListBase::eArgValType_StringQuotedNumberPath, 1));
>  
>  
> Based on the GDB MI documentation (at 
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fsourceware.org%2fgdb%2fonlinedocs%2fgdb%2fGDB_002fMI-Breakpoint-Commands.html%23GDB_002fMI-Breakpoint-Commands=01%7c01%7cPierson.Lee%40microsoft.com%7c2f7fe625424341c8101908d3a79d5c33%7c72f988bf86f141af91ab2d7cd011db47%7c1=vA0kav9epp3zRa4QivQ9wmimjEHYiJ0AiQfJcGKdzEs%3d)
>  for -break-insert shows:
>  
> ‘-f’
> If location cannot be parsed (for example if it refers to unknown files or 
> functions), create a pending breakpoint. Without this flag, gdb will report 
> an error, and won't create a breakpoint, if location cannot be parsed. 
>  
> Is there a reason why it requires a parameter and what should this parameter 
> be ?
>  
> Thanks
> Pierson
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> 

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

[Ted Woodward via lldb-dev]

I wanted a log with Eclipse talking to lldb-mi to see if it was doing anything 
odd. It's not:

-exec-continue --thread-group i1
<   5> send packet: $c#63
-list-thread-groups i1   



We have lldb-mi launch hexagon-sim automatically; it launches the same way 
debugserver does, with reverse-connect. I'd expect an -exec-run to do this 
automatically for you. No need to specify parameters to debugserver.



Here is some of a log of Eclipse talking to lldb-mi talking to a Hexagon 
target. It looks very similar, except for -exec-run instead of -target-select 
remote and -exec-continue:

TX:21-break-insert -t -f main

RX:=breakpoint-modified,bkpt={number="3",type="breakpoint",disp="keep",enabled="y",addr="0x1e002eec",func="test_main_start",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="100",pending=["downscaleBy2.c:100"],times="0",original-location="downscaleBy2.c:100"}
TX:22-list-thread-groups

RX:(gdb)
RX:21^done,bkpt={number="4",type="breakpoint",disp="del",enabled="y",addr="0x1e002d5c",func="main",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="72",pending=["main"],times="0",original-location="main"}
RX:(gdb)
TX:23-exec-run

RX:=breakpoint-modified,bkpt={number="4",type="breakpoint",disp="del",enabled="y",addr="0x1e002d5c",func="main",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="72",pending=["main"],times="0",original-location="main"}
RX:(gdb)
RX:22^done,groups=[{id="i1",type="process",executable="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\hexagon_Debug_toolv80_v60/downscaleBy2_q"}]
RX:(gdb)
RX:23^running
RX:=thread-group-started,id="i1",pid="1"
RX:(gdb)
RX:=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x1e002f38",func="test_main_start",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="121",pending=["downscaleBy2.c:110"],times="0",original-location="downscaleBy2.c:110"}
RX:(gdb)
RX:=breakpoint-modified,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x1e002df0",func="test_main_start",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="96",pending=["downscaleBy2.c:96"],times="0",original-location="downscaleBy2.c:96"}
RX:(gdb)
RX:=breakpoint-modified,bkpt={number="3",type="breakpoint",disp="keep",enabled="y",addr="0x1e002eec",func="test_main_start",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="100",pending=["downscaleBy2.c:100"],times="0",original-location="downscaleBy2.c:100"}
RX:(gdb)
RX:=breakpoint-modified,bkpt={number="4",type="breakpoint",disp="del",enabled="y",addr="0x1e002d5c",func="main",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="72",pending=["main"],times="1",original-location="main"}
TX:24-list-thread-groups --available

RX:(gdb)
RX:=thread-created,id="1",group-id="i1"
RX:=thread-created,id="2",group-id="i1"
RX:=thread-created,id="3",group-id="i1"
RX:=thread-created,id="4",group-id="i1"
RX:=thread-selected,id="1"
RX:(gdb)
RX:23^running
RX:=thread-group-started,id="i1",pid="1"
RX:(gdb)
RX:=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x1e002f38",func="test_main_start",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="121",pending=["downscaleBy2.c:110"],times="0",original-location="downscaleBy2.c:110"}
RX:(gdb)
RX:=breakpoint-modified,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x1e002df0",func="test_main_start",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="96",pending=["downscaleBy2.c:96"],times="0",original-location="downscaleBy2.c:96"}
RX:(gdb)
RX:=breakpoint-modified,bkpt={number="3",type="breakpoint",disp="keep",enabled="y",addr="0x1e002eec",func="test_main_start",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="100",pending=["downscaleBy2.c:100"],times="0",original-location="downscaleBy2.c:100"}
RX:(gdb)
RX:=breakpoint-modified,bkpt={number="4",type="breakpoint",disp="del",enabled="y",addr="0x1e002d5c",func="main",file="downscaleBy2.c",fullname="C:\installSDK\Hexagon_SDK\3.0\examples\common\downscaleBy2\src/downscaleBy2.c",line="72",pending=["main"],times="1",original-location="main"}
TX:24-list-thread-groups --available

RX:(gdb)
RX:=thread-created,id="1",group-id="i1"
RX:=thread-created,id="2",group-id="i1"
RX:=thread-created,id="3",group-id="i1"
RX:=thread-created,id="4",group-id="i1"

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

[Greg Clayton via lldb-dev]

> On Jul 11, 2016, at 1:31 AM, dipt...@gmail.com wrote:
> 
> Thanks Ted.
> Attached is the GDB log after enabling log while executing same commands 
> manually from command prompt.
> 

Is this the GDB log while still running lldb-mi? I would like to see a log of 
any program that actually runs using "gdb" as the MI program. This will allow 
us to see a working example. We know it isn't working with LLDB and I was 
thinking we can get hints of what is expected with an actual GDB doing the MI.

> Yes, I am running debug server manually.  I am facing issues with "GDB (DSF) 
> Automatic Remote Debugging Launcher" as eclipse is not passing correct 
> parameter to debug server. Below is the Eclipse console output with automatic 
> mode:
> 
> echo $PWD'>'
> /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver
>  :192.168.116.140:1234  /Users/admin/Documents/workspace/Hello\ World\ C++\ 
> Project/Debug/Hello\ World\ C++\ Project;exit

What is the extra ":" before the address? debugserver doesn't support this 
syntax and that is why it is causing issues.

> dshiralkar-mactest:~ admin$ echo $PWD'>'
> /Users/admin>
> dshiralkar-mactest:~ admin$ 
> /Applications/Xcode.app/Contents/SharedFrameworks/LL 
> DB.framework/Versions/A/Resources/debugserver :192.168.116.140:1234  
> /Users/admi n/Documents/workspace/Hello\ World\ C++\ Project/Debug/Hello\ 
> World\ C++\ Projec t;exit
> debugserver-@(#)PROGRAM:debugserver  PROJECT:debugserver-350.0.21.9
>  for x86_64.
> Usage:
>   debugserver host:port [program-name program-arg1 program-arg2 ...]
>   debugserver /path/file [program-name program-arg1 program-arg2 ...]
>   debugserver host:port --attach=
>   debugserver /path/file --attach=
>   debugserver host:port --attach=
>   debugserver /path/file --attach=
> logout
> 
> Please let me know your thoughts.
> 
> 
> -- 
> Have a nice day!
> Regards,
> Dipti
> 
> 
> 
> On Fri, Jul 8, 2016 at 9:55 PM, Ted Woodward  
> wrote:
> A few thoughts:
> 
> 1)  I think lldb-mi now takes lldb commands, so you could do the log in 
> your manual copy/paste. The command you want is:
> 
> log enable gdb-remote packets
> 
> Do it after the stop, before the –break-insert. You’ll get a bunch of data 
> after the –break-insert, then do the –exec-continue and –list-thread-groups, 
> and send the data that comes out after those.
> 
>  
> 
> 2)  I see from the log that you’re doing a –target-select remote. Are you 
> running debugserver manually? What happens if you don’t run debugserver, and 
> have Eclipse do –exec-run instead of –target-select remote?
> 
> The original Codeplay implementation of lldb-mi talked to the Hexagon 
> Simulator, but didn’t have a way to launch it, so they only used 
> –target-select remote, and not –exec-run. Debugserver can be launched 
> automatically, so –exec-run should work.
> 
>  
> 
> 3)  This is an answer to Greg’s question about –exec-continue and 
> –list-thread-groups. I was going to ask the same thing, but I looked over 
> some old logs I had. Eclipse called –list-thread-groups while the target was 
> running, and it worked fine. This was with a 2 year old lldb-mi, but I’d 
> expect a modern lldb-mi to work as well. The spec at 
> https://sourceware.org/gdb/onlinedocs/gdb/Thread-groups.html talks about what 
> this command does. It gives a list of process groups that the debugger is 
> debugging, so it doesn’t matter if a certain process is running or not.
> 
>  
> 
>  
> 
> --
> 
> Qualcomm Innovation Center, Inc.
> 
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
> 
>  
> 
> From: dipt...@gmail.com [mailto:dipt...@gmail.com] 
> Sent: Friday, July 08, 2016 6:23 AM
> To: Ted Woodward 
> Cc: Greg Clayton ; LLDB 
> 
> 
> Subject: Re: [lldb-dev] LLDB-MI from Eclipse hangs
> 
>  
> 
> Thanks Ted for your reply.
> 
> I tried the same command that eclipse uses manually from command prompt. It 
> hangs after same last command "-exec-continue --thread-group i1". Attached is 
> the lldb-mi sample at that time.
> 
>  
> 
> While debugging from Eclipse I am going to Run--> Debug Configurations--> 
> C/C++ Remote Applications-->  and then click on Debug 
> button. And then all the commands are executed by Eclipse automatically. I do 
> not see two different steps as attach and continue. So I am not sure how to 
> pass command "log enable gdb-remote packets". May be I am missing something. 
> Can you please help me here, so that I can get the required log as suggested 
> by you? Thanks.
> 
>  
> 
>  
> 
> -- 
> 
> Have a nice day!
> Regards,
> Dipti
> 
> On Fri, Jul 8, 2016 at 4:01 AM, Ted Woodward  
> wrote:
> 
> I don’t see anything in the log that looks like a problem. I’ve got 2 
> thoughts:
> 
>  
> 
> 1)  Have you tried manual debugging with the same 

Re: [lldb-dev] lock() fails on my lldb::Type

[Greg Clayton via lldb-dev]

When a class inherits from std::enable_shared_from_this, like Type does:


class Type :
public std::enable_shared_from_this,
public UserID
{


You must construct your object directly into a shared pointer right away so 
that it can setup the std::weak_ptr (a member variable in the 
std::enable_shared_from_this class) inside of Type correctly. So your code must 
be:

TypeSP  p_type(new Type(LLDB_INVALID_UID,
NULL,
name,
1024, // just ... 
NULL,
LLDB_INVALID_UID,
Type::eEncodingIsUID,
whatever,
compiler_type,
Type::eResolveStateFull));

Don't make a pointer first, then put that pointer into a shared pointer.

Greg Clayton


> On Jul 9, 2016, at 11:10 AM, Nat! via lldb-dev  
> wrote:
> 
> From the looks of it, lldb uses 
> `ObjCLanguageRuntime::LookupInCompleteClassCache` to create a lldb::Type for 
> an Objective C class, by looking through the modules. In my circumstances 
> (one being on Linux), it doesn't find a symbol for the class and puts my 
> classname into `m_negative_complete_class_cache`. Which is no good for me.
> 
> I try to fix this by looking through my DeclVendor, check if a class is 
> defined in the runtime, and if yes I create a substitute lldb::Type.
> 
> ``
>   DeclVendor *vendor = GetDeclVendor();
>   if( vendor)
>   {
> std::vector decls;
> uint32_t  count = vendor->FindDecls( name, false, 1, decls);
> 
> if( count)
> {
> if (clang::ObjCInterfaceDecl *interface_decl = 
> llvm::dyn_cast( decls[ 0]))
> {
>CompilerType compiler_type = 
> ClangASTContext::GetTypeForDecl(interface_decl);
>Declaration whatever;
>Type   *type = new Type(  LLDB_INVALID_UID,
>  NULL,
>  name,
>  1024, // just ... 
>  NULL,
>  LLDB_INVALID_UID,
>  Type::eEncodingIsUID,
>  whatever,
>  compiler_type,
>  Type::eResolveStateFull);
> TypeSP  p_type( type);
> 
> p_type->SetIsCompleteObjCClass( true);
> m_complete_class_cache[ name] = p_type;
> 
> return( p_type);
>  }
>   }
>   }
>}
>m_negative_complete_class_cache.insert(name);
>return TypeSP();
> }
> ```
> 
> This doesn't fail outright, but the next time LookupInCompleteClassCache is 
> called, the codes does this `lock()` with my cached type and fails:
> 
> ```
>   TypeSP complete_type_sp (complete_class_iter->second.lock());
> 
>if (complete_type_sp)
>return complete_type_sp;
> ```
> 
> Then the code will create a duplicate type. So what do I have to do, so that 
> my lldb::Type doesn't return NULL when lock() is called ?
> 
> Nat!
> 
> ___
> 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

[Ilia K via lldb-dev]

I'm not very familiar with Eclipse, so if there is a way to change start
sequence of MI commands, just remove "gdb-set target-async off" or replace
with "gdb-set target-async on". If not, then rebuild lldb-mi with
"disabled" target-async feature:
```
$ svn diff tools/lldb-mi/
Index: tools/lldb-mi/MICmdCmdGdbSet.cpp
===
--- tools/lldb-mi/MICmdCmdGdbSet.cpp (revision 275049)
+++ tools/lldb-mi/MICmdCmdGdbSet.cpp (working copy)
@@ -247,7 +247,7 @@

 // Turn async mode on/off.
 CMICmnLLDBDebugSessionInfo
(CMICmnLLDBDebugSessionInfo::Instance());
-rSessionInfo.GetDebugger().SetAsync(bAsyncMode);
+rSessionInfo.GetDebugger().SetAsync(true); // Be always in async

 return MIstatus::success;
 }
```


On Mon, Jul 11, 2016 at 10:36 AM,  wrote:

> Thank you all for your reply.
> Attached is the GDB log.  It looks like synchronous from log :
>
> (gdb)
>
> -exec-continue --thread-group i1
>
> <   5> send packet: $c#63
>
> -list-thread-groups i1
>
>
>
> Greg,
>
> Can there be some issue with remote debug server? I am using below command:
>
>
>
> *cd 
> /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources*
>
> *./debugserver 192.168.116.140:1234 
> --attach=2775*
>
> *debugserver-@(#)PROGRAM:debugserver  PROJECT:debugserver-350.0.21.9*
>
> * for x86_64.*
>
> *Attaching to process 2775...*
>
> *Listening to port 1234 for a connection from 192.168.116.140...*
>
> *Waiting for debugger instructions for process 2775.*
>
>
>
> Ilia,
>
>
> How did you do this "I forced lldb-mi to stay in async mode and it was
> enough for me and Eclipse." ? How do I change the lldb-mi commands executed
> by eclipse. It would be great if you can help me with this.
>
>
> --
> Have a nice day!
> Regards,
> Dipti
>
>
> On Mon, Jul 11, 2016 at 2:01 AM, Ilia K  wrote:
>
>> Good point Greg! Eclipse turns on synchronous mode in lldb-mi but works
>> as if it's in async. I faced with that problem year and a half ago and I
>> still don't know why Eclipse does it. The last time, I forced lldb-mi to
>> stay in async mode and it was enough for me and Eclipse.
>>
>> As for missing ^running, seems that it just not implemented. We support
>> only asynchronous *running notifications (which aren't being shown in sync
>> mode).
>>
>> - Ilia
>> On Jul 8, 2016 8:19 PM, "Greg Clayton via lldb-dev" <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> From the sample I see that LLDB is in synchronous mode. It was caused by:
>>>
>>> > 313,449 12-gdb-set target-async off
>>> > 313,453 12^done
>>>
>>> This sets LLDB into synchronous mode where if you say "-exec-continue",
>>> that command won't return until the target stops. This causes lldb-mi to
>>> not process any commands until your process stops or exits. Not sure that
>>> this is what we want. We can see the handler for "target-async" below:
>>>
>>> //++
>>> 
>>> // Details: Carry out work to complete the GDB set option 'target-async'
>>> to prepare
>>> //  and send back information asked for.
>>> // Type:Method.
>>> // Args:vrWords - (R) List of additional parameters used by this
>>> option.
>>> // Return:  MIstatus::success - Function succeeded.
>>> //  MIstatus::failure - Function failed.
>>> // Throws:  None.
>>> //--
>>> bool
>>> CMICmdCmdGdbSet::OptionFnTargetAsync(const CMIUtilString::VecString_t
>>> )
>>> {
>>> bool bAsyncMode = false;
>>> bool bOk = true;
>>>
>>> if (vrWords.size() > 1)
>>> // Too many arguments.
>>> bOk = false;
>>> else if (vrWords.size() == 0)
>>> // If no arguments, default is "on".
>>> bAsyncMode = true;
>>> else if (CMIUtilString::Compare(vrWords[0], "on"))
>>> bAsyncMode = true;
>>> else if (CMIUtilString::Compare(vrWords[0], "off"))
>>> bAsyncMode = false;
>>> else
>>> // Unrecognized argument.
>>> bOk = false;
>>>
>>> if (!bOk)
>>> {
>>> // Report error.
>>> m_bGbbOptionFnHasError = true;
>>> m_strGdbOptionFnError =
>>> MIRSRC(IDS_CMD_ERR_GDBSET_OPT_TARGETASYNC);
>>> return MIstatus::failure;
>>> }
>>>
>>> // Turn async mode on/off.
>>> CMICmnLLDBDebugSessionInfo
>>> (CMICmnLLDBDebugSessionInfo::Instance());
>>> rSessionInfo.GetDebugger().SetAsync(bAsyncMode);
>>>
>>> return MIstatus::success;
>>> }
>>>
>>> So we see that it sets the debugger into synchronous mode. I don't know
>>> MI well enough to know if this is desired, but seeing that eclipse quickly
>>> follows up the -exec-continue with a -list-thread-groups, I am guessing
>>> this isn't what we want. I would be interested to see the MI log from a GDB
>>> that actually works to see what the packet responses are expected to look
>>> like.
>>>
>>> Greg
>>>
>>> > On Jul 8, 2016, at 12:06 AM,