Re: [lldb-dev] Error when using lldb-mi built with LLDB_DISABLE_PYTHON

2016-06-20 Thread Ilia K via lldb-dev
Hi!

Unfortunately, this is a regression introduced in r251082. From that moment
lldb-mi requires LLDB_DISABLE_PYTHON=0 for showing wide chars:
char16/char32 types.

If you cannot enable python support, I suggest you to:
1. ignore MI_add_summary's errors by returning TRUE:
```
Index: tools/lldb-mi/MICmnLLDBDebugger.cpp
===
--- tools/lldb-mi/MICmnLLDBDebugger.cpp (revision 273137)
+++ tools/lldb-mi/MICmnLLDBDebugger.cpp (working copy)
@@ -58,7 +58,7 @@
uint32_t options, bool regex = false)
 {
 #if defined(LLDB_DISABLE_PYTHON)
-return false;
+return true;
 #else
 lldb::SBTypeSummary summary =
lldb::SBTypeSummary::CreateWithCallback(cb, options);
 return summary.IsValid() ?
category.AddTypeSummary(lldb::SBTypeNameSpecifier(typeName, regex),
summary) : false;
```

In this case, wide chars will not be expanded unlike simple chars:
```
(gdb) -var-create - * cp
^done,name="var7",numchild="1",value="0x00400cb4
\"\\t\\\"hello\\\"\\n\"",type="const char *",thread-id="1",has_more="0"
(gdb) -var-create - * u16p
^done,name="var9",numchild="1",value="0x00400d64",type="const
char16_t *",thread-id="1",has_more="0"
```

2. or you can try to revert r251082.

Please fill a bug report on llvm.org/bugs and tell me if you have other
issues.


On Sat, Jun 18, 2016 at 3:35 AM, Pierson Lee (PIE) via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi,
>
>
>
> I’ve built lldb on tag release_38 (3.8.1) with the flag
> LLDB_DISABLE_PYTHON=1 and I’m getting the below error when running lldb-mi:
>
>
>
> MI: Error: Driver. LLDB Debugger.
>
> MI: Error: Driver Manager. Driver 'Machine Interface Driver Version:
> 1.0.0.9' (ID:'MIDriver') initialise failed. Driver. LLDB Debugger.
>
>
>
> Am I missing something?
>
>
>
> Thanks
>
> Pierson
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>


-- 
- Ilia
___
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-10 Thread Ilia K via lldb-dev
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" 
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().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, dipt...@gmail.com wrote:
> >
> > Thanks Greg. Attached is the file after sampling lldb-mi. Please let me
> know if you can find some clue from it.
> >
> > --
> > Have a nice day!
> > Regards,
> > Dipti
> >
> >
> > On Fri, Jul 8, 2016 at 5:49 AM, 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 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 (g

Re: [lldb-dev] bug in TestMiGdbSetShow.test_lldbmi_gdb_set_target_async_off?

2016-07-10 Thread Ilia K via lldb-dev
Hi Ted!

As noted in the copied code, *running is async notification and it only
must be shown in async mode. The test checks that it's not being shown in
sync mode. So the test is correct.

On Thu, May 19, 2016 at 12:56 AM, Ted Woodward via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Packages/Python/lldbsuite/test/tools/lldb-mi/TestMiGdbSetShow.py, in
> test_lldbmi_gdb_set_target_async_off we have this code:
>
>
>
> self.runCmd("-gdb-set target-async off")
>
>
>
> …
>
>
>
> self.runCmd("-exec-run")
>
> unexpected = [ "\*running" ] # "\*running" is async notification
>
> it = self.expect(unexpected + [ "@\"argc=1rn" ])
>
> if it < len(unexpected):
>
> self.fail("unexpected found: %s" % unexpected[it])
>
>
>
> But lldb-mi does the right thing, expect won’t match “running”, so the
> self.expect command fails, which causes the test to error out. Shouldn’t
> the self.expect be in a try, with an except being a pass?
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>


-- 
- Ilia
___
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-11 Thread 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
&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().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, dipt...@gmail.

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

2016-07-17 Thread Ilia K via lldb-dev
Hi Marc-Andre!

Ok, I'll review your patches. But if you have a couple of minutes, please
fill the bug form at llvm.org/bugs first.

On Mon, Jul 18, 2016 at 12:26 AM, Marc-Andre Laperle via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi,
>
> I am currently working on integrating LLDB-MI in Eclipse CDT so that
> it works more or less out of the box in the next CDT release due in
> September (setting the lldb-mi path automatically, etc). For this
> specific issue, I made it so that it simply does not send the
> target-async command from Eclipse. I have worked around a few other
> issues and I'll look at creating bugs in LLDB's Bugzilla and sending
> patches to LLDB in the upcoming weeks.
>
> Here are some issues I worked around but would like to fix on the LLDB
> side:
> 1. -breakpoint-insert doesn't handle locations that look like absolute
> paths (because of leading /)
> 2. Executable path has to be absolute
>
> This Eclipse integration is still very much in progress but in case
> you are curious, the code is here:
> https://github.com/MarkZ3/Eclipse-CDT-WIP/tree/lldb-mi
>
> Regards,
> Marc-Andre
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>



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


Re: [lldb-dev] LLDB REFORMATTING IN PROGRESS

2016-09-08 Thread Ilia K via lldb-dev
Hi!

clang-formatting of my patch changed the style outside the patch (diff:
https://reviews.llvm.org/D24331?vs=70653&id=70654). Am I doing something
wrong?

On Wed, Sep 7, 2016 at 1:06 PM, Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Windows unit tests passing now. All clear.
>
> On 7 September 2016 at 09:54, Pavel Labath  wrote:
> > I am still seeing errors when building windows unittests. I'll have a
> > change for fixing that soon. Apart from that everything else looks
> > good on our side. I'll send an all clear once the unit tests get green
> > on windows.
> >
> > pl
> >
> > On 6 September 2016 at 23:26, Zachary Turner via lldb-dev
> >  wrote:
> >> I think Windows is good.
> >>
> >> On Tue, Sep 6, 2016 at 3:10 PM Zachary Turner 
> wrote:
> >>>
> >>> Everything compiles on Windows now but all the tests are failing with
> >>> ERROR.  I'm looking into this now.
> >>>
> >>> On Tue, Sep 6, 2016 at 2:26 PM Ed Maste via lldb-dev
> >>>  wrote:
> 
>  On 6 September 2016 at 17:17, Kate Stone via lldb-dev
>   wrote:
>  > The storm of commit messages might be a subtle clue, but here it is
>  > officially: the reformatting is complete and I’ve verified that no
>  > tests
>  > regressed locally in our macOS suite.  Please begin any validation
>  > process
>  > you’ve signed up for on another platform, and if changes are
> necessary
>  > go
>  > ahead and land them individually.
> 
>  FreeBSD currently fails to build due to header reordering in
>  source/Host/freebsd/Host.cpp which I'll sort out shortly.
> 
>  I'd like to request that we avoid any functional changes other than
>  those restoring builds to green, until we get the "all clear" from
>  everyone who's signed up to validate other platforms.
> 
>  -Ed
>  ___
>  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
>



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


Re: [lldb-dev] LLDB REFORMATTING IN PROGRESS

2016-09-08 Thread Ilia K via lldb-dev
But what about SVN users? :)
Okay, I know format can be applied for modified fragments only. But why did
we leave some places unformatted? I thought "clang-format -i `find include
source tools -name '*.[cpp|h]'`" ends with empty diff.

On Thu, Sep 8, 2016 at 10:19 AM, Zachary Turner  wrote:

> In order to clang-format only the diff, you should use the "git
> clang-format" extension command. Search for git-clang-format (yes, that one
> has an extra dash), and there should be instructions inside
> On Thu, Sep 8, 2016 at 12:16 AM Ilia K  wrote:
>
>> Hi!
>>
>> clang-formatting of my patch changed the style outside the patch (diff:
>> https://reviews.llvm.org/D24331?vs=70653&id=70654). Am I doing something
>> wrong?
>>
>> On Wed, Sep 7, 2016 at 1:06 PM, Pavel Labath via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> Windows unit tests passing now. All clear.
>>>
>>> On 7 September 2016 at 09:54, Pavel Labath  wrote:
>>> > I am still seeing errors when building windows unittests. I'll have a
>>> > change for fixing that soon. Apart from that everything else looks
>>> > good on our side. I'll send an all clear once the unit tests get green
>>> > on windows.
>>> >
>>> > pl
>>> >
>>> > On 6 September 2016 at 23:26, Zachary Turner via lldb-dev
>>> >  wrote:
>>> >> I think Windows is good.
>>> >>
>>> >> On Tue, Sep 6, 2016 at 3:10 PM Zachary Turner 
>>> wrote:
>>> >>>
>>> >>> Everything compiles on Windows now but all the tests are failing with
>>> >>> ERROR.  I'm looking into this now.
>>> >>>
>>> >>> On Tue, Sep 6, 2016 at 2:26 PM Ed Maste via lldb-dev
>>> >>>  wrote:
>>> 
>>>  On 6 September 2016 at 17:17, Kate Stone via lldb-dev
>>>   wrote:
>>>  > The storm of commit messages might be a subtle clue, but here it
>>> is
>>>  > officially: the reformatting is complete and I’ve verified that no
>>>  > tests
>>>  > regressed locally in our macOS suite.  Please begin any validation
>>>  > process
>>>  > you’ve signed up for on another platform, and if changes are
>>> necessary
>>>  > go
>>>  > ahead and land them individually.
>>> 
>>>  FreeBSD currently fails to build due to header reordering in
>>>  source/Host/freebsd/Host.cpp which I'll sort out shortly.
>>> 
>>>  I'd like to request that we avoid any functional changes other than
>>>  those restoring builds to green, until we get the "all clear" from
>>>  everyone who's signed up to validate other platforms.
>>> 
>>>  -Ed
>>>  ___
>>>  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
>>>
>>
>>
>>
>> --
>> - Ilia
>>
>


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


Re: [lldb-dev] running lldb-mi with LLDB_DISABLE_PYTHON

2016-09-20 Thread Ilia K via lldb-dev
Hi!

Please see possible workarounds in
https://llvm.org/bugs/show_bug.cgi?id=28253.

On Tue, Sep 20, 2016 at 10:57 AM, Chunseok Lee via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Dear lldb dev team,
>
> I am working on running lldb-mi on arm32 device(like rpi) for remote
> debugging usage.
> Is there any way to run lldb-mi with python disabled ?
> When building lldb with LLDB_DISABLE_PYTHON, it seems that dataformatter
> initialization is failed due to the following code in
> MICmnLLDBDebugger.cpp:59
>
> //++
> //--
> --
> // MI summary helper routines
> static inline bool MI_add_summary(lldb::SBTypeCategory category,
>   const char *typeName,
>   lldb::SBTypeSummary::FormatCallback cb,
>   uint32_t options, bool regex = false) {
> #if defined(LLDB_DISABLE_PYTHON)
>   return false;
> #else
>   lldb::SBTypeSummary summary =
>   lldb::SBTypeSummary::CreateWithCallback(cb, options);
>   return summary.IsValid()
>  ? category.AddTypeSummary(
>lldb::SBTypeNameSpecifier(typeName, regex), summary)
>  : false;
> #endif
> }
>
> Thank you.
>
> BR,
> Chunseok Lee
>
> --
> Where Do We come from? What Are We? Where Are We Going?
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>


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


Re: [lldb-dev] lldb-mi stopped after '-target-select remote'

2016-10-19 Thread Ilia K via lldb-dev
Hi!

I think it's okay that remote target is stopped when you connect to it.
Just skip it.

On Wed, Oct 19, 2016 at 8:14 AM, Chunseok Lee via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I have noticed that lldb-mi stopped after executing "-target-select
> remote".
> My execution step is like:
> -
> $ lldb-server g --platform=remote-linux "*:1234"
>
> $ lldb-mi
> (gdb)
> -file-exec-and-symbols /home/twoflower/a.out
> (gdb)
> -target-select remote localhost:1234
> .
> (gdb)
> *stopped,reason="signal-received",signal-name="
> SIGSTOP",signal-meaning="Stop",frame={level="0",addr="
> 0x7f4bdf53e2d0",func="??",file="??",fullname="??",line="
> -1"},thread-id="1",stopped-threads="all"
> -
>
> In my project, I dont want to stop there.
> Where is a good point to investigate the code triggering SIGSTOP ?
>
>
> BR,
> Chunseok Lee
>
> --
> Where Do We come from? What Are We? Where Are We Going?
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>


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


Re: [lldb-dev] non-stop mode with lldb-mi?

2017-02-01 Thread Ilia K via lldb-dev
Please check `-gdb-set target.async` option. Probably that's what you need.

On Thu, Feb 2, 2017 at 1:44 AM, Ted Woodward via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Does lldb-mi support non-stop mode?
>
>
>
> If so, is there a way to set it besides “settings set target.non-stop-mode
> true”?
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>


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


Re: [lldb-dev] [llvm-dev] lldb-mi functionality

2017-03-28 Thread Ilia K via lldb-dev
-llvm-dev

We support most MI commands and lldb-mi can be used alongside with Eclipse.
So probably it would work also with gdbgui.  They are pretty compatible :)



On Tue, Mar 14, 2017 at 6:08 PM, Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Not too much documentation unfortunately, but I'm cc'ing lldb-dev@.
> Hopefully one of the people who have worked on authoring / maintaining this
> will see it and chime in.
>
> On Fri, Mar 10, 2017 at 7:36 PM Chad Smith via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
>> Is there any documentation on what machine interface (mi) commands are 
>> implemented in lldb-mi, and how compatible those commands are with gdb's mi?
>>
>> I'm asking for this project:  https://github.com/cs01/gdbgui
>>
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>


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


Re: [lldb-dev] Emacs LLDB support & the GDB/MI Interface

2017-08-06 Thread Ilia K via lldb-dev
You are probably got it but yes, -file-list-exec-source-files and
-break-list commands are not implemented yet. I'll try to find the time to
fix it.

On Mon, Jul 31, 2017 at 9:44 PM, Eli Zaretskii via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> > From: "Ted Woodward" 
> > Cc: 
> > Date: Mon, 31 Jul 2017 13:24:31 -0500
> >
> > The best thing to do is give us a list of commands that are failing, in
> a bug opened in Bugzilla at http://bugs.llvm.org .
>
> The URL I provided (after several mistaken attempts ;-) included a
> lits of the failing commands.
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>



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


Re: [lldb-dev] lldb-mi doesn't work on MS-Windows

2017-08-17 Thread Ilia K via lldb-dev
Hi!

Did you build it from sources? If yes, please provide your configure
options.

On Tue, Aug 15, 2017 at 7:10 PM, Eli Zaretskii via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Since at least two snapshots ago, lldb-mi no longer works on
> MS-Windows:
>
>   D:\usr\archive>lldb-mi d:\usr\bin\emacs.exe
>   MI: Error: Driver. LLDB Debugger.
>   MI: Error: Driver Manager. Driver 'Machine Interface Driver Version:
> 1.0.0.9' (ID:'MIDriver') initialise failed. Driver. LLDB Debugger.
>
> It actually reacts the same to any invocation, even if you only want
> it to display the usage:
>
>   D:\usr\LLVM\bin>lldb-mi --help
>   MI: Error: Driver. LLDB Debugger.
>   MI: Error: Driver Manager. Driver 'Machine Interface Driver Version:
> 1.0.0.9' (ID:'MIDriver') initialise failed. Driver. LLDB Debugger.
>
> What am I doing wrong?
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>



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


Re: [lldb-dev] lldb-mi doesn't work on MS-Windows

2017-08-17 Thread Ilia K via lldb-dev
Yep, it requires python from some time.

Guys, how you think is it okay to have such dependency for lldb-mi, or we
should try to get rid of this?

On Aug 17, 2017 21:11, "Ted Woodward"  wrote:

Looking at the source, I think the failure is in
CMICmnLLDBDebugger::Initialize().
The snapshot is built without debug info, so I can't debug it.

lldb.exe in the snapshot is built without python support. I seem to recall
a discussion a few months ago about lldb-mi requiring python; that might be
the issue.

In any case, we should contact the buildbot owner and arrange for lldb to
be built with python. We could provide one with python and one without. The
one with python would require the user to install the same python that the
bot used to build lldb.

Ted

--
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 Eli
> Zaretskii via lldb-dev
> Sent: Thursday, August 17, 2017 9:20 AM
> To: Ilia K 
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] lldb-mi doesn't work on MS-Windows
>
> > From: Ilia K 
> > Date: Thu, 17 Aug 2017 14:59:01 +0300
> > Cc: LLDB 
> >
> > Did you build it from sources? If yes, please provide your configure
options.
>
> No, I installed the snapshot available from https://llvm.org/builds/.
> (I used the 32-bit binaries from there.)
> ___
> 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] [cfe-dev] [llvm-dev] [11.0.0 Release] Release Candidate 6 is here

2020-11-29 Thread Ilia K via lldb-dev
Hi! Can someone tell me what configure / build flags do you use when
building these packages (.tar.xz)? I guess there should be a script, but is
it available somewhere?

Thanks in advance,
- Ilia

On Mon, Oct 12, 2020 at 11:28 AM Diana Picus via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi,
>
> Uploaded Arm & AArch64:
> 95449841c1c4b0164414e58b1053a3877e3bd73d9b1b3e15e5d1d4c2fd5cae1e
> clang+llvm-11.0.0-rc6-aarch64-linux-gnu.tar.xz
> 40ba7c35c5430cc2775b8dbf0bc4687d7a466c29332b89193de903ea4557fb05
> clang+llvm-11.0.0-rc6-armv7a-linux-gnueabihf.tar.xz
>
> Same as previous rc's.
>
> Cheers,
> Diana
>
> On Sat, 10 Oct 2020 at 04:46, Shoaib Meenai via cfe-dev
>  wrote:
> >
> > Uploaded macOS binaries to
> https://drive.google.com/file/d/1OVsImFG99a0jNOWc1IDhRvER3CvbGmFp/view?usp=sharing
> .
> >
> > The SHA-256 is:
> >
> > b35f3b6ce4de703f015bdf9d936f530b28c752737c2dd60715bd3d098787652b
> clang+llvm-11.0.0-rc6-x86_64-apple-darwin.tar.xz
> >
> > The full test results are:
> >
> > Failed Tests (2):
> >   libunwind :: libunwind_01.pass.cpp
> >   libunwind :: signal_frame.pass.cpp
> >
> > Testing Time: 3211.12s
> >   Unsupported  :  3200
> >   Passed   : 68254
> >   Expectedly Failed:   264
> >   Failed   : 2
> >
> > The libunwind tests failed with rc5 and also fail for 10.0.1 on my
> machine, so it's likely an environmental issue. (See
> https://lists.llvm.org/pipermail/llvm-dev/2020-October/145513.html for my
> previous investigation into the libunwind failures, where we determined
> they shouldn't be launch-blocking.)
> >
> > (It might be easier to give me SFTP access, to save Tobias the trouble
> of having to download and reupload to the SFTP.)
> >
> > On 10/7/20, 7:40 AM, "llvm-dev on behalf of Hans Wennborg via llvm-dev"
> 
> wrote:
> >
> > Hello once again,
> >
> > A few more issues appeared, so here is yet another release candidate:
> > llvmorg-11.0.0-rc6 was just tagged.
> >
> > Source code and docs are available at
> > https://prereleases.llvm.org/11.0.0/#rc6
> > and
> > https://github.com/llvm/llvm-project/releases/tag/llvmorg-11.0.0-rc6
> >
> > Pre-built binaries will be added as they become ready.
> >
> > Please file reports for any bugs you find as blockers of
> > https://llvm.org/pr46725
> >
> > Release testers, if you still have cycles, please take this for a
> > quick spin. The changes from rc5 are minimal, and hopefully we can
> tag
> > this as the final version very soon now.
> >
> > Thanks,
> > Hans
> > ___
> > LLVM Developers mailing list
> > llvm-...@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> > ___
> > cfe-dev mailing list
> > cfe-...@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>


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


Re: [lldb-dev] lldb-mi plans

2015-09-25 Thread Ilia K via lldb-dev
On Fri, Sep 25, 2015 at 2:33 PM, Ilia K  wrote:

> oops..
> -lldb-...@cs.uiuc.edu
> +lldb-dev@lists.llvm.org
>
> On Fri, Sep 25, 2015 at 2:30 PM, Hafiz Abid Qadeer 
> wrote:
>
>> Sounds reasonable to me.
>>
>> On Fri, Sep 25, 2015 at 8:02 AM, Ilia K  wrote:
>>
>>> Hi guys!
>>>
>>> I found the following things that can be simplified:
>>> 1. Add CMIUtilString(std::string) ctor:
>>> ```
>>> CMIUtilString(std::string().c_str()) -> CMIUtilString(std::string())
>>> ```
>>> Patch: http://reviews.llvm.org/D13158
>>> 2. Rename CMICmnBase::SetErrorDescriptionn to
>>> CMICmnBase::SetErrorDescriptionFormat
>>> 3. Allow to pass unformatted arguments (i.e. format string + tuple of
>>> parameters) to CMICmnBase::SetErrorDescription:
>>> ```
>>> SetErrorDescription(CMIUtilString::Format(MIRSRC(IDS_CMDFACTORY_ERR_INVALID_CMD_NAME),
>>> vMiCmd.c_str()))
>>> ```
>>> and then remove CMICmnBase::SetErrorDescriptionFormat.
>>> 4. Allow to pass unformatted arguments to CMICmdBase::SetError:
>>> ```
>>> SetError(CMIUtilString::Format(MIRSRC(IDS_CMD_ERR_OPTION_NOT_FOUND),
>>> m_cmdData.strMiCmd.c_str(), m_constStrArgThread.c_str()));
>>> ```
>>>
>>> Thoughts?
>>>
>>> --
>>> - Ilia
>>>
>>
>>
>
>
> --
> - Ilia
>



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