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

[via lldb-dev]

Thanks Ilia.

For now I check running Eclipse commands manually by changing to "gdb-set
target-async *on*" and it solves the issue for manual run. I will try to
find out how to change these commands in eclipse otherwise I will rebuild
lldvmi. I will keep you posted...


-- 
Have a nice day!
Regards,
Dipti

On Mon, Jul 11, 2016 at 1:21 PM, Ilia K  wrote:

> 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
> &rSessionInfo(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
 &vrWords)
 {
 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
 &rSessionInfo(CMICmnLLDBDebugSessionInfo::Instance());
 rSessionInfo.GetDebugger().Set

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

[Ted Woodward via lldb-dev]

It looks like the current implementation expects the -f to be right before the 
break location. So "-break-insert main" or "-break-insert -t -f main -d" would 
work, but "-break-insert -t main -f -d" would not.
It also looks as if restricting the breakpoint to the thread id (incorrectly) 
only works if a condition is set.

From my reading of the spec at 
https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Breakpoint-Commands.html , 
-f should not take a parameter.

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


-Original Message-
From: Pierson Lee (PIE) [mailto:pierson@microsoft.com] 
Sent: Monday, July 11, 2016 3:59 PM
To: Ted Woodward ; jing...@apple.com; 'LLDB' 

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

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&data=01%7c01%7cPierson.Lee%40microsoft.com%7c2f7fe625424341c8

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

[Pierson Lee (PIE) via lldb-dev]

Cool. I'll put together a bug report and a possible fix.

Thanks for looking at it!

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

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

It looks like the current implementation expects the -f to be right before the 
break location. So "-break-insert main" or "-break-insert -t -f main -d" would 
work, but "-break-insert -t main -f -d" would not.
It also looks as if restricting the breakpoint to the thread id (incorrectly) 
only works if a condition is set.

From my reading of the spec at 
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fsourceware.org%2fgdb%2fonlinedocs%2fgdb%2fGDB_002fMI-Breakpoint-Commands.html&data=01%7c01%7cPierson.Lee%40microsoft.com%7c0c3dd7c7e910436c1cb708d3aa838b7b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=vByn8jcB4fumv4A7Z1uq0AoiUo0KN1jqEV0j3trKRNs%3d
 , -f should not take a parameter.

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


-Original Message-
From: Pierson Lee (PIE) [mailto:pierson@microsoft.com] 
Sent: Monday, July 11, 2016 3:59 PM
To: Ted Woodward ; jing...@apple.com; 'LLDB' 

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

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::Pars

[lldb-dev] Proposed change in multi-line edit behavior (Return = end/append, Meta+Return = line break)

[Kate Stone via lldb-dev]

I’ve posted a new Phabricator review discussing this change @ 
http://reviews.llvm.org/D22284.  Comments welcome!

Editing multi-line content in a terminal environment involves a lot of 
trade-offs. When LLDB's multi-line editing support was first introduced for 
expressions / REPL contexts the behavior was as follows:

The Return key is treated as a line-break except at the end of the input 
buffer, where a completeness test is applied

This worked well enough when writing code, and makes it trivial to insert new 
lines above code you've already typed. Just use cursor navigation to move up 
and type freely. Where it was awkward is that the gesture to insert a line 
break and end editing is conflated for most people. Sometimes you want Return 
to end the editing session and other times you want to insert a line break.

This patch proposes a change in the behavior as follows:

The Return key is treated as the end of editing except at the end of the input 
buffer, where a completeness test is applied
The Meta+Return sequence is always treated as a line break. This is consistent 
with conventions in Facebook and elsewhere since Alt/Option+Return is often 
mapped to Meta+Return. The unfortunate exception is on macOS where this *can* 
be the case, but isn't by default. Sigh.

Note that by design both before and after the patch pasting a Return character 
always introduces a line break.

Kate Stone k8st...@apple.com 
 Xcode Low Level Tools

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

[lldb-dev] Help text overhaul

[Kate Stone via lldb-dev]

I’ve posted a new Phabricator review discussing this change @ 
http://reviews.llvm.org/D22286 .  Comments 
welcome!

LLDB help content has accumulated over time without a recent attempt to review 
it for consistency, accuracy, and clarity. This patch attempts to address all 
of the above while keeping the text relatively terse.

Kate Stone k8st...@apple.com 
 Xcode Low Level Tools

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