Re: [lldb-dev] Inquiry about LLDB remote protocol

[Aidan Dodds via lldb-dev]

The GDB RSP, which LLDB RSP is derived from is certainly state-full and 
maintains an notion of the current thread for queries (reading 
registers, etc..) and for execution commands (stepping), see the 'H' packet.
The RSP has evolved quite a bit however and extended packets were 
introduced that do take TID's as a parameter (vcont for instance).

Hopefully someone can chip in who is more familiar with lldb-server however.

As for your other question, the RSP should however be relatively 
platform independent as far as state-fullness goes, I don't think and of 
the upstream lldb platforms keep an kind of special state.


Disclaimer... Its been a little while since I have had to really dig 
into RSP so its all liable to have changed.



On 29/03/2016 10:57, Ravitheja Addepally via lldb-dev wrote:

Hello,
  I wanted to know if the remote protocol of LLDB is state less or 
not ? When i say state I am referring to if LLDB remembers the current 
process or thread being debugged (which would mean we dont need to 
specify that in the client to server packets ) . I was looking at the 
GDBRemoteCommunicationServerLLGS and found that most of the packets 
did not have the pid or thread id being passed to the server , so is 
it safe to assume that the protocol is statefull ? is this assumption 
also valid for all OS's ?


---Ravi


___
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] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

[Pavel Labath via lldb-dev]

Zachary, all,

after overcoming some problems, mostly unrelated to MSVC, we have
finally managed to switch to VS2015. I think that means there are no
more VS2013 users remaining. Given that, shall we start the process to
formally allow c++ features, which were blocked due to VS2013 until
now? I am mostly thinking about thread-safe function-static variable
initialization and alias templates here...

what do you think?
pl


On 4 February 2016 at 20:23, Ted Woodward  wrote:
> We can change to 3+2015; if you guys don't think 2+2013 is useful, we'll do 
> that.
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
>
> -Original Message-
> From: Pavel Labath [mailto:lab...@google.com]
> Sent: Thursday, February 04, 2016 10:01 AM
> To: Ted Woodward
> Cc: Zachary Turner; LLDB
> Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported 
> toolchain
>
> Hi all.
>
> we (android lldb team) are starting to transition to VS2015 as well.
> For now, the plan is to stick to python 2.7, but if we encounter problems 
> there, the backup plan is to go to python 3 as well. Until then (I estimate 
> that will take 1--2 weeks) our buildbot 
>  will continue 
> building 2.7+2013 and we will be making sure it works, so please don't check 
> in any VS2013 incompatible code (yet).
>
> Ted: If you can't switch to the 3+2015 combination (which I *do* recommend 
> you try), maybe you can go half-way and switch to 2.7+2015 (I can show you 
> how to build python 2.7 with VS2015). If you stick with 2.7+2013 combo, it 
> will soon be up to you to chase anyone who adds 2013-breaking changes...
>
> pl
>
>
> On 2 February 2016 at 23:42, Ted Woodward via lldb-dev 
>  wrote:
>> No, it turned red Friday night/Saturday morning.
>>
>>
>>
>> Last good build:
>>
>> http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15167
>>
>>
>>
>> First bad build:
>>
>> http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15168
>>
>>
>>
>> It went red because of the change to VS2015/Python 3.5.
>>
>>
>>
>> --
>>
>> Qualcomm Innovation Center, Inc.
>>
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>>
>>
>>
>> From: Zachary Turner [mailto:ztur...@google.com]
>> Sent: Tuesday, February 02, 2016 5:28 PM
>>
>>
>> To: Ted Woodward; LLDB
>> Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an
>> unsupported toolchain
>>
>>
>>
>> BTW, I expect that your buildbot has been experiencing the problems
>> with the
>> x86 / x64 toolchain for quite some time, because it's not really
>> relevant to how much memory your machine has, but just that it was
>> using an x86 toolchain at all.  Has it been red for a long time?
>>
>>
>>
>> On Tue, Feb 2, 2016 at 1:48 PM Zachary Turner  wrote:
>>
>> You may have to make some changes to the zorg scripts to keep that working.
>> I didn't realize there were any other bots building LLDB, so I made
>> some changes that will default everything to VS2015 and Py3.
>>
>>
>>
>> BTW, is your builder doing a debug build or a release build?  When
>> doing a debug build clang now requires more memory than can fit in a
>> 4GB address space to link, so using an x86 toolchain won't work
>> anymore.  I forced a change to use the amd64_x86 toolchain, but this
>> won't work unless the version of python used by buildbot is a 64-bit
>> Python distro (because Python.exe is what ultimately calls vcvarsall
>> and cmake and it inherits the environment of the parent).
>>
>>
>>
>> So I think you will need to do all this as well.
>>
>>
>>
>> On Tue, Feb 2, 2016 at 1:44 PM Ted Woodward
>> 
>> wrote:
>>
>> Then maybe we should keep it 2013/py2.7, until llvm requires 2015.
>>
>>
>>
>> --
>>
>> Qualcomm Innovation Center, Inc.
>>
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>>
>>
>>
>> From: Zachary Turner [mailto:ztur...@google.com]
>> Sent: Tuesday, February 02, 2016 3:43 PM
>>
>>
>> To: Ted Woodward; LLDB
>> Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an
>> unsupported toolchain
>>
>>
>>
>> It's Server 2008 R2 technically, which is the server version of Win 7
>> (same API set, same OS features, etc).  So yea, I'm pretty confident
>> that test coverage is going to be 100% the same across both.  It's
>> just a matter of if you want to have something that you maintain /
>> have control over, or if you want to test something in a different way than 
>> what we're testing.
>>
>>
>>
>> On Tue, Feb 2, 2016 at 1:29 PM Ted Woodward
>> 
>> wrote:
>>
>> Yours is Win Server 2008; ours is Win 7. I don’t know if that matters.
>>
>>
>>
>> --
>>
>> Qualcomm Innovation Center, Inc.
>>
>> 

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

[Zachary Turner via lldb-dev]

Great work all. I would certainly welcome that, greg might want to weigh in
as well.

The other big one is thread_local keyword, lldb's ThreadLocal class remains
broken on Windows, and thread_local is the only way to fix it
On Tue, Mar 29, 2016 at 8:17 AM Pavel Labath  wrote:

> Zachary, all,
>
> after overcoming some problems, mostly unrelated to MSVC, we have
> finally managed to switch to VS2015. I think that means there are no
> more VS2013 users remaining. Given that, shall we start the process to
> formally allow c++ features, which were blocked due to VS2013 until
> now? I am mostly thinking about thread-safe function-static variable
> initialization and alias templates here...
>
> what do you think?
> pl
>
>
> On 4 February 2016 at 20:23, Ted Woodward 
> wrote:
> > We can change to 3+2015; if you guys don't think 2+2013 is useful, we'll
> do that.
> >
> > --
> > Qualcomm Innovation Center, Inc.
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
> >
> > -Original Message-
> > From: Pavel Labath [mailto:lab...@google.com]
> > Sent: Thursday, February 04, 2016 10:01 AM
> > To: Ted Woodward
> > Cc: Zachary Turner; LLDB
> > Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an
> unsupported toolchain
> >
> > Hi all.
> >
> > we (android lldb team) are starting to transition to VS2015 as well.
> > For now, the plan is to stick to python 2.7, but if we encounter
> problems there, the backup plan is to go to python 3 as well. Until then (I
> estimate that will take 1--2 weeks) our buildbot <
> http://lab.llvm.org:8011/builders/lldb-windows7-android> will continue
> building 2.7+2013 and we will be making sure it works, so please don't
> check in any VS2013 incompatible code (yet).
> >
> > Ted: If you can't switch to the 3+2015 combination (which I *do*
> recommend you try), maybe you can go half-way and switch to 2.7+2015 (I can
> show you how to build python 2.7 with VS2015). If you stick with 2.7+2013
> combo, it will soon be up to you to chase anyone who adds 2013-breaking
> changes...
> >
> > pl
> >
> >
> > On 2 February 2016 at 23:42, Ted Woodward via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >> No, it turned red Friday night/Saturday morning.
> >>
> >>
> >>
> >> Last good build:
> >>
> >> http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15167
> >>
> >>
> >>
> >> First bad build:
> >>
> >> http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15168
> >>
> >>
> >>
> >> It went red because of the change to VS2015/Python 3.5.
> >>
> >>
> >>
> >> --
> >>
> >> Qualcomm Innovation Center, Inc.
> >>
> >> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> >> a Linux Foundation Collaborative Project
> >>
> >>
> >>
> >> From: Zachary Turner [mailto:ztur...@google.com]
> >> Sent: Tuesday, February 02, 2016 5:28 PM
> >>
> >>
> >> To: Ted Woodward; LLDB
> >> Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an
> >> unsupported toolchain
> >>
> >>
> >>
> >> BTW, I expect that your buildbot has been experiencing the problems
> >> with the
> >> x86 / x64 toolchain for quite some time, because it's not really
> >> relevant to how much memory your machine has, but just that it was
> >> using an x86 toolchain at all.  Has it been red for a long time?
> >>
> >>
> >>
> >> On Tue, Feb 2, 2016 at 1:48 PM Zachary Turner 
> wrote:
> >>
> >> You may have to make some changes to the zorg scripts to keep that
> working.
> >> I didn't realize there were any other bots building LLDB, so I made
> >> some changes that will default everything to VS2015 and Py3.
> >>
> >>
> >>
> >> BTW, is your builder doing a debug build or a release build?  When
> >> doing a debug build clang now requires more memory than can fit in a
> >> 4GB address space to link, so using an x86 toolchain won't work
> >> anymore.  I forced a change to use the amd64_x86 toolchain, but this
> >> won't work unless the version of python used by buildbot is a 64-bit
> >> Python distro (because Python.exe is what ultimately calls vcvarsall
> >> and cmake and it inherits the environment of the parent).
> >>
> >>
> >>
> >> So I think you will need to do all this as well.
> >>
> >>
> >>
> >> On Tue, Feb 2, 2016 at 1:44 PM Ted Woodward
> >> 
> >> wrote:
> >>
> >> Then maybe we should keep it 2013/py2.7, until llvm requires 2015.
> >>
> >>
> >>
> >> --
> >>
> >> Qualcomm Innovation Center, Inc.
> >>
> >> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> >> a Linux Foundation Collaborative Project
> >>
> >>
> >>
> >> From: Zachary Turner [mailto:ztur...@google.com]
> >> Sent: Tuesday, February 02, 2016 3:43 PM
> >>
> >>
> >> To: Ted Woodward; LLDB
> >> Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an
> >> unsupported toolchain
> >>
> >>
> >>
> >> It's Server 2008 R2 technically, which is the server 

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

[Aidan Dodds via lldb-dev]

At Codeplay we are currently building on windows using a split of MSVC 
2013 and MSVC 2015.
In theory we are happy to move entirely to 2015, but until then we would 
have to work around any 2013 breakages.



On 29/03/2016 16:16, Pavel Labath via lldb-dev wrote:

Zachary, all,

after overcoming some problems, mostly unrelated to MSVC, we have
finally managed to switch to VS2015. I think that means there are no
more VS2013 users remaining. Given that, shall we start the process to
formally allow c++ features, which were blocked due to VS2013 until
now? I am mostly thinking about thread-safe function-static variable
initialization and alias templates here...

what do you think?
pl


On 4 February 2016 at 20:23, Ted Woodward  wrote:

We can change to 3+2015; if you guys don't think 2+2013 is useful, we'll do 
that.

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

-Original Message-
From: Pavel Labath [mailto:lab...@google.com]
Sent: Thursday, February 04, 2016 10:01 AM
To: Ted Woodward
Cc: Zachary Turner; LLDB
Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported 
toolchain

Hi all.

we (android lldb team) are starting to transition to VS2015 as well.
For now, the plan is to stick to python 2.7, but if we encounter problems there, the 
backup plan is to go to python 3 as well. Until then (I estimate that will take 1--2 
weeks) our buildbot  
will continue building 2.7+2013 and we will be making sure it works, so please don't 
check in any VS2013 incompatible code (yet).

Ted: If you can't switch to the 3+2015 combination (which I *do* recommend you 
try), maybe you can go half-way and switch to 2.7+2015 (I can show you how to 
build python 2.7 with VS2015). If you stick with 2.7+2013 combo, it will soon 
be up to you to chase anyone who adds 2013-breaking changes...

pl


On 2 February 2016 at 23:42, Ted Woodward via lldb-dev 
 wrote:

No, it turned red Friday night/Saturday morning.



Last good build:

http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15167



First bad build:

http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15168



It went red because of the change to VS2015/Python 3.5.



--

Qualcomm Innovation Center, Inc.

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



From: Zachary Turner [mailto:ztur...@google.com]
Sent: Tuesday, February 02, 2016 5:28 PM


To: Ted Woodward; LLDB
Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an
unsupported toolchain



BTW, I expect that your buildbot has been experiencing the problems
with the
x86 / x64 toolchain for quite some time, because it's not really
relevant to how much memory your machine has, but just that it was
using an x86 toolchain at all.  Has it been red for a long time?



On Tue, Feb 2, 2016 at 1:48 PM Zachary Turner  wrote:

You may have to make some changes to the zorg scripts to keep that working.
I didn't realize there were any other bots building LLDB, so I made
some changes that will default everything to VS2015 and Py3.



BTW, is your builder doing a debug build or a release build?  When
doing a debug build clang now requires more memory than can fit in a
4GB address space to link, so using an x86 toolchain won't work
anymore.  I forced a change to use the amd64_x86 toolchain, but this
won't work unless the version of python used by buildbot is a 64-bit
Python distro (because Python.exe is what ultimately calls vcvarsall
and cmake and it inherits the environment of the parent).



So I think you will need to do all this as well.



On Tue, Feb 2, 2016 at 1:44 PM Ted Woodward

wrote:

Then maybe we should keep it 2013/py2.7, until llvm requires 2015.



--

Qualcomm Innovation Center, Inc.

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



From: Zachary Turner [mailto:ztur...@google.com]
Sent: Tuesday, February 02, 2016 3:43 PM


To: Ted Woodward; LLDB
Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an
unsupported toolchain



It's Server 2008 R2 technically, which is the server version of Win 7
(same API set, same OS features, etc).  So yea, I'm pretty confident
that test coverage is going to be 100% the same across both.  It's
just a matter of if you want to have something that you maintain /
have control over, or if you want to test something in a different way than 
what we're testing.



On Tue, Feb 2, 2016 at 1:29 PM Ted Woodward

wrote:

Yours is Win Server 2008; ours is Win 7. I don’t know if that matters.



--

Qualcomm Innovation Center, Inc.

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

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

[Ted Woodward via lldb-dev]

We’re currently still using Python 2.7 and VS 2013 on the Qualcomm Hexagon 
team. We expect to keep pulling from upstream until about the middle of June, 
then branch for a release. We’d rather not switch to Python 3.5/VS 2105 for 
this release.

 

--

Qualcomm Innovation Center, Inc.

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

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Zachary 
Turner via lldb-dev
Sent: Tuesday, March 29, 2016 11:40 AM
To: Aidan Dodds ; lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported 
toolchain

 

Keep in mind that llvm bumps minimum vs version roughly once a year, and it's 
probably about that time. So the discussion here is just about whether to do it 
earlier than llvm, not whether to do it all.

So whether it's now or a few months from now, at some point you're going to 
have to handle these incompatibilities in your own fork out of tree

On Tue, Mar 29, 2016 at 9:11 AM Aidan Dodds via lldb-dev 
 > wrote:

At Codeplay we are currently building on windows using a split of MSVC
2013 and MSVC 2015.
In theory we are happy to move entirely to 2015, but until then we would
have to work around any 2013 breakages.


On 29/03/2016 16:16, Pavel Labath via lldb-dev wrote:
> Zachary, all,
>
> after overcoming some problems, mostly unrelated to MSVC, we have
> finally managed to switch to VS2015. I think that means there are no
> more VS2013 users remaining. Given that, shall we start the process to
> formally allow c++ features, which were blocked due to VS2013 until
> now? I am mostly thinking about thread-safe function-static variable
> initialization and alias templates here...
>
> what do you think?
> pl
>
>
> On 4 February 2016 at 20:23, Ted Woodward   > wrote:
>> We can change to 3+2015; if you guys don't think 2+2013 is useful, we'll do 
>> that.
>>
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
>> Linux Foundation Collaborative Project
>>
>> -Original Message-
>> From: Pavel Labath [mailto:lab...@google.com  ]
>> Sent: Thursday, February 04, 2016 10:01 AM
>> To: Ted Woodward
>> Cc: Zachary Turner; LLDB
>> Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported 
>> toolchain
>>
>> Hi all.
>>
>> we (android lldb team) are starting to transition to VS2015 as well.
>> For now, the plan is to stick to python 2.7, but if we encounter problems 
>> there, the backup plan is to go to python 3 as well. Until then (I estimate 
>> that will take 1--2 weeks) our buildbot 
>>  will continue 
>> building 2.7+2013 and we will be making sure it works, so please don't check 
>> in any VS2013 incompatible code (yet).
>>
>> Ted: If you can't switch to the 3+2015 combination (which I *do* recommend 
>> you try), maybe you can go half-way and switch to 2.7+2015 (I can show you 
>> how to build python 2.7 with VS2015). If you stick with 2.7+2013 combo, it 
>> will soon be up to you to chase anyone who adds 2013-breaking changes...
>>
>> pl
>>
>>
>> On 2 February 2016 at 23:42, Ted Woodward via lldb-dev 
>>  > wrote:
>>> No, it turned red Friday night/Saturday morning.
>>>
>>>
>>>
>>> Last good build:
>>>
>>> http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15167
>>>
>>>
>>>
>>> First bad build:
>>>
>>> http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15168
>>>
>>>
>>>
>>> It went red because of the change to VS2015/Python 3.5.
>>>
>>>
>>>
>>> --
>>>
>>> Qualcomm Innovation Center, Inc.
>>>
>>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>>> a Linux Foundation Collaborative Project
>>>
>>>
>>>
>>> From: Zachary Turner [mailto:ztur...@google.com  
>>> ]
>>> Sent: Tuesday, February 02, 2016 5:28 PM
>>>
>>>
>>> To: Ted Woodward; LLDB
>>> Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an
>>> unsupported toolchain
>>>
>>>
>>>
>>> BTW, I expect that your buildbot has been experiencing the problems
>>> with the
>>> x86 / x64 toolchain for quite some time, because it's not really
>>> relevant to how much memory your machine has, but just that it was
>>> using an x86 toolchain at all.  Has it been red for a long time?
>>>
>>>
>>>
>>> On Tue, Feb 2, 2016 at 1:48 PM Zachary Turner >>  > wrote:
>>>
>>> You may have to make some changes to the zorg scripts to keep that working.
>>> I didn't realize there were any other bots building LLDB, so I made
>>> some changes that will default everything to VS2015 and Py3.
>>>
>>>
>>>
>>> BTW, is your builder doing a 

Re: [lldb-dev] Inquiry about LLDB remote protocol

[Greg Clayton via lldb-dev]

> On Mar 29, 2016, at 2:57 AM, Ravitheja Addepally via lldb-dev 
>  wrote:
> 
> Hello,
>   I wanted to know if the remote protocol of LLDB is state less or not ? 
> When i say state I am referring to if LLDB remembers the current process or 
> thread being debugged (which would mean we dont need to specify that in the 
> client to server packets ) . I was looking at the 
> GDBRemoteCommunicationServerLLGS and found that most of the packets did not 
> have the pid or thread id being passed to the server , so is it safe to 
> assume that the protocol is statefull ?

Yes. There is the notion that you have one process that may or may not be there 
when you connect. When and if a process does exist, it assumes it won't change. 
Threads can be selected and many packets operate of the current thread. We have 
also added new packets to allow us to append a thread ID suffix to existing 
packets, like reading and writing registers. This allows us to save a packet 
round trip so we don't always have to say "set thread to thread 123" and then 
"read register 12". 

> is this assumption also valid for all OS's ?

Yep. Very stateful.

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

Re: [lldb-dev] How to detach from stop mode without causing signal in inferior on Linux?

[Pavel Labath via lldb-dev]

Hi,

are you doing a SBProcess.Detach() before you kill the debugger? If
that doesn't help could you send me the gdb-remote packet form
(execute command: log enable -f /some/file.log gdb-remote packets), so
I can get a better idea of what is going on.

cheers,
pl


On 29 March 2016 at 00:21, Jeffrey Tan via lldb-dev
 wrote:
> Hi,
>
> When user tries to stop debugging, we call SBDebugger.Destroy(), then
> SBDebugger.Terminate() and exit the python process. This works well on mac,
> but on linux in running mode. However, I found if the debugger hits
> breakpoint first, then user stops debugging, the inferior is killed with
> siginal:
> "Trace/breakpoint trap"
>
> I tried to call SBTarget.DeleteAllBreakpoints() first before killing
> debugger. Still the same result.
>
> Jeffrey
>
> ___
> 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] SBProcess::Detach kills target

[Pavel Labath via lldb-dev]

There is no system restriction which prevents you from doing this.
(Without any investigation) my guess would be that your inferior is
dying of SIGHUP, which it receives when we close the master end of its
pty. Could you check whether the behavior persists if your app blocks
SIGHUP and/or you launch it with "process launch --no-stdio").

pl

On 25 March 2016 at 23:33, Jim Ingham via lldb-dev
 wrote:
> I vaguely remember that not all Unixen support detaching from a process that 
> is a child of the debugger that is attached to it.  If you run the process 
> under gdb & detach, does the process survive?  This may not be an exact test, 
> since gdb may use procfs rather than ptrace, I don't know any more...  But if 
> it doesn't work for gdb, it's probably a system limitation.
>
> Anyway, launch then detach works as Greg described on OS X, so all the bits 
> down to the call into the Process plugin's Detach is working correctly.  So 
> either there's a bug in llgs or in the Process plugin for Linux's detach.
>
> Jim
>
>
>> On Mar 25, 2016, at 3:57 PM, Greg Clayton via lldb-dev 
>>  wrote:
>>
>> Calling SBProcess::Detach() on a process that is currently running should 
>> always detach and this seems like a bug. This might be this way because if 
>> you launch a process in LLDB and then quit:
>>
>> % lldb /bin/ls
>> (lldb) b malloc
>> (lldb) run
>> (lldb) quit
>>
>> This should kill the process if it was launched and detach if we attached. 
>> But only when we quit without telling it to do something. If we did:
>>
>> % lldb /bin/ls
>> (lldb) b malloc
>> (lldb) run
>> (lldb) detach
>>
>> Then this should always detach if the user explicitly requests it no matter 
>> how it was launched.
>>
>>> On Mar 25, 2016, at 3:35 PM, Eugene Birukov via lldb-dev 
>>>  wrote:
>>>
>>> Hi,
>>>
>>> Is this expected behavior or am I doing something wrong?
>>>
>>> I am running my C++ program that uses LLDB API on Linux Ubuntu 15.10.
>>>
>>> If I attach to already running process then SBProcess::Detach() behaves as 
>>> expected - my debugger quits and the target keeps running. But if the 
>>> target was launched by my debugger, then detach just kills it. Is there any 
>>> way to leave the target running?
>>>
>>> Thanks,
>>> Eugene
>>> ___
>>> 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
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Inquiry about LLDB remote protocol

[Ravitheja Addepally via lldb-dev]

Hello,
  I wanted to know if the remote protocol of LLDB is state less or not
? When i say state I am referring to if LLDB remembers the current process
or thread being debugged (which would mean we dont need to specify that in
the client to server packets ) . I was looking at the
GDBRemoteCommunicationServerLLGS and found that most of the packets did not
have the pid or thread id being passed to the server , so is it safe to
assume that the protocol is statefull ? is this assumption also valid for
all OS's ?

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