What's triggering one of the OS Plugin methods to get run on this separate
thread? I would expect SetPrivateState would just cause the private stop event
to get broadcast to the private state thread, and then that would wake up and
then it would be the one to call the OS Plugin to do it's job.
That clarified things, thanks!
I think, this is the reason:
ProcessRunLock &Process::GetRunLock() {
if (m_private_state_thread.EqualsThread(Host::GetCurrentThread()))
return m_private_run_lock;
else
return m_public_run_lock;
}
In our case the current thread is not m_private_state_thr
https://bugs.llvm.org/show_bug.cgi?id=26102
Adrian McCarthy changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEW
> On Feb 21, 2019, at 11:22 AM, Tatyana Krasnukha via lldb-dev
> wrote:
>
> > lldb Process::SetPrivateState (stopped) stop_id = 2
> > error: error: process must be stopped.
>
> These two lines are printed from different threads, you cannot be sure the
> real order of execution i
> lldb Process::SetPrivateState (stopped) stop_id = 2
> error: error: process must be stopped.
These two lines are printed from different threads, you cannot be sure the real
order of execution is the same.
The plugin should subscribe on public state change events and wait until one
It seems that the process plugin uses the Process::SetPrivateState at the
right time. If you look at the log, you will see that the process is
already in the '*private* *stopped'* state when the OS plugin is invoked.
(lldb) c
lldb Process::Resume -- locking run lock
lldb Pr
> -Original Message-
> From: lldb-dev On Behalf Of Pavel Labath
> via lldb-dev
> Sent: Thursday, February 21, 2019 8:35 AM
> To: Davide Italiano
> Cc: LLDB
> Subject: [EXT] Re: [lldb-dev] [RFC]The future of pexpect
>
> On 21/02/2019 00:03, Davide Italiano wrote:
> > I found out that t
I don't think lldb has a separate release notes document. Adding an
lldb section to the llvm ones sounds good to me.
On Thu, Feb 21, 2019 at 5:19 PM Raphael Isemann wrote:
>
> I'm not sure what to do with potential LLDB release notes. Should I
> just add a LLDB section to the LLVM release notes o
I'm not sure what to do with potential LLDB release notes. Should I
just add a LLDB section to the LLVM release notes or do we actually
have a separate file for LLDB like clang/libcxx/lld do?
- Raphael
Am Di., 19. Feb. 2019 um 16:26 Uhr schrieb Hans Wennborg via lldb-dev
:
>
> Hello everyone,
>
>
On 21/02/2019 15:35, Pavel Labath via lldb-dev wrote:
So we may not even be able to get away with just using the system one
and skipping tests when it's not present.
s/may not/may/
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.o
On 21/02/2019 00:03, Davide Italiano wrote:
I found out that there are tests that effectively require
interactivity. Some of the lldb-mi ones are an example.
A common use-case is that of sending SIGTERM in a loop to make sure
`lldb-mi` doesn't crash and handle the signal correctly.
This function
11 matches
Mail list logo
