Re: [lldb-dev] SBProcess::Detach kills target
We are not sending the SIGHUP, it is automatically getting sent by the
OS when the master end of the pty gets closed. The reason you are not
seeing this in the attach scenario is that we do not intercept
inferior stdio in this case (it's not possible, or desirable, since
the process is already running). This is also the reason
SBProcess.GetSTDOUT does not return anything in the attach scenario. I
am not familiar with the details of the Mac implementation and I
cannot tell you why is this not happening there.
I guess one way to fix this would be to have a special mode of
starting the inferior without a controlling terminal, but I am not
sure if this would be a generally useful feature. What is it that you
are trying to do anyway?
pl
On 30 March 2016 at 23:03, Eugene Birukov wrote:
> Just a wild guess - is this SIGHUP because stdin/stdout are broken? I.e. the
> debugger closes its pty's on detach and that causes the signal?
> What is the behavior on MAC?
>
>
> To: lab...@google.com
> Date: Wed, 30 Mar 2016 14:49:33 -0700
> CC: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] SBProcess::Detach kills target
> From: lldb-dev@lists.llvm.org
>
>
> Right, my bad. The problem was that when debugger detaches the stdio does
> not go anywhere so I failed to see my printf.
>
> Still, is this how it is supposed to be? I naively assume that if we don't
> send SIGHUP in attach scenario we should not send it in launch scenario too.
>
> Thanks,
> Eugene
>
>> From: lab...@google.com
>> Date: Wed, 30 Mar 2016 10:22:33 +0100
>> Subject: Re: [lldb-dev] SBProcess::Detach kills target
>> To: eugen...@hotmail.com
>> CC: jing...@apple.com; lldb-dev@lists.llvm.org
>>
>> So I have made a small test program (which does nothing but spin in a
>> loop), and indeed it is the SIGHUP that kills it after detach. If the
>> test program blocks the signal, then it continues running even after
>> detach:
>> $ cat a.c
>> #include
>> #include
>>
>> int main() {
>> signal(SIGHUP, SIG_IGN);
>> for (;;) sleep(1);
>> }
>> $ cc a.c -g
>> $ ps -A | grep a.out
>> $ ~/ll/build/dbg/bin/lldb ./a.out
>> (lldb) target create "./a.out"
>> Current executable set to './a.out' (x86_64).
>> (lldb) b 6
>> Breakpoint 1: where = a.out`main + 19 at a.c:6, address =
>> 0x00400590
>> (lldb) r
>> Process 13416 launched: './a.out' (x86_64)
>> Process 13416 stopped
>> * thread #1: tid = 13416, 0x00400590 a.out`main + 19 at a.c:6,
>> name = 'a.out', stop reason = breakpoint 1.1
>> frame #0: 0x00400590 a.out`main + 19 at a.c:6
>> 3
>> 4 int main() {
>> 5 signal(SIGHUP, SIG_IGN);
>> -> 6 for (;;) sleep(1);
>> 7 }
>> (lldb) detach
>> Process 13416 detached
>> (lldb) q
>> $ ps -A | grep a.out
>> 13416 ? 00:00:00 a.out
>>
>>
>> On 29 March 2016 at 18:38, Eugene Birukov wrote:
>> > I believe this is not SIGHUP on debugger exit. I am using my own C++
>> > program
>> > that calls into LLDB API. So, this program is still alive after calling
>> > SBProcess::Detach() but the target dies. Also, the target intercepts
>> > SIGHUP
>> > to do cleanup before exiting. I put printf there, it was not hit.
>> The fact whether your program is alive irrelevant. What matters is
>> that by cleaning up the process structure, we will also close the
>> master end of the pty used for inferior communication, and this is
>> what causes the SIGHUP. For that reason you also cannot use a printf
>> to do diagnostics as the output has nowhere to go. Note that lldb's
>> behavior here will be different from gdb as gdb does not do stdio
>> redirection, and has the inferior share the pty with the debugger (in
>> which case your program will die when you close the terminal window).
>>
>> >
>> > I tried interactive LLDB, the target is not there:
>> >
>> > Process 49145 stopped
>> > * thread #1: tid = 49145, ..., stop reason = signal SIGSTOP
>> > frame #0: 0x76a5bbed libc.so.6 at syscall-template.S:81
>> > (lldb) detach
>> > Process 49145 detached
>> > (lldb) q
>> > eugene@EUGENEBI-L1:~/tmp$ ps
>> > PID TTY TIME CMD
>> > 30714 pts/17 00:00:00 bash
>> > 49259 pts/17 00:00:00 ps
>> Note that the inferior will not show up here even if it exists, as ps
>> will only list the processes with the same tty, but at this point the
>> inferior process has no tty.
>>
>> Good luck with your investigations.
>>
>> pl
>
> ___ 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] Review of API and remote packets
Hello all,
I am currently working on enabling Intel (R) Processor Trace
collection for lldb. I have done some previous discussions in this mailing
list on this topic but just to summarize , the path we chose was to
implement raw trace collection in lldb and the trace will be decoded
outside LLDB. I wanted to expose this feature through the SB API's and for
trace data transfer I wish to develop new communication packets. Now I want
to get the new API's and packet specifications reviewed by the dev list.
Please find the specification below ->
lldb::SBError SBProcess::StartTrace(lldb::tid_t threadId, const
SBTraceConfig &config)
Start tracing for thread - threadId with trace configuration config.
SBTraceConfig would contain the following fields-
-> TraceType - ProcessorTrace, SoftwareTrace , any trace
technology etc
-> size of trace buffer
-> size of meta data buffer
Returns error in case starting trace was unsuccessful, which could
occur by reasons such as
picking non existent thread, target does not support TraceType selected
etc.
lldb::SBError SBProcess::StopTrace(lldb::tid_t threadId)
Stop tracing for thread - threadId. Tracing should be enabled already
for thread, else error is returned.
size_t SBProcess::DumpTraceData(lldb::tid_t threadId, void *buf, size_t
size, SBError &sberror)
Dump the raw trace data for threadId in buffer described by pointer buf
and size. Tracing should be enabled already for thread else error
is sent in sberror. The actual size of filled buffer is returned by API.
size_t SBProcess::DumpTraceMetaData(lldb::tid_t threadId, void *buf, size_t
size, SBError &sberror)
Dump the raw trace meta data for threadId in buffer described by
pointer buf and size. Tracing should be enabled already for thread
else error is sent in sberror. The actual size of filled buffer is
returned by API.
LLDB Trace Packet Specification
QTrace:1:,,,
Packet for starting tracing, where -
-> threadid - stands for thread to trace
-> type - Type of tracing to use, it will be like type of trace
mechanism to use.
For e.g ProcessorTrace, SoftwareTrace , any trace
technology etc and if
that trace is not supported by target error will be
returned. In Future
we can also add more parameters in the packet
specification, which can be type specific
and the server can parse them based on what type it
read in the beginning.
-> buffersize - Size for trace buffer
-> metabuffersize - Size of Meta Data
QTrace:0:
Stop tracing thread with threadid,{Trace needs to be started of-course
else error}
qXfer:trace:buffer:read:annex:,
Packet for reading the trace buffer
-> threadid - thread ID, of-course if tracing is not
started for this thread error will be returned.
-> byte_count - number of bytes to read, in case trace captured is
less than byte_count, then only that much trace will
be returned in response packet.
qXfer:trace:meta:read:annex:,
Similar Packet as above except it reads meta data
___
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
It might be also possible to run an expression that will route
stdin/stdout/stderr to /dev/null before detaching if we know that we have a
master/slave pty hooked up the the inferior's in/out/err. We could run an
expression like:
int fd = open("/dev/null", O_RDWR);
close(0);
close(1);
close(2);
dup2(fd, 0);
dup2(fd, 1);
dup2(fd, 2);
Then the program could continue normally? So this might need to be part of
detach code, but it should only be done if we used a pty.
One other thing to try is to write a 0x04 to the master side of the pty. Since
the master/slave is emulating a terminal, this is how you shut it down as if
you just close the master side, and if the other process is doing a fgets(...)
from the slave side, it won't cause the slave to exit, but writing the EOF
(0x04) byte to the master side _will_ cause the fgets(...) to exit on the other
side.
Greg
> On Mar 31, 2016, at 1:16 AM, Pavel Labath via lldb-dev
> wrote:
>
> We are not sending the SIGHUP, it is automatically getting sent by the
> OS when the master end of the pty gets closed. The reason you are not
> seeing this in the attach scenario is that we do not intercept
> inferior stdio in this case (it's not possible, or desirable, since
> the process is already running). This is also the reason
> SBProcess.GetSTDOUT does not return anything in the attach scenario. I
> am not familiar with the details of the Mac implementation and I
> cannot tell you why is this not happening there.
> I guess one way to fix this would be to have a special mode of
> starting the inferior without a controlling terminal, but I am not
> sure if this would be a generally useful feature. What is it that you
> are trying to do anyway?
>
> pl
>
> On 30 March 2016 at 23:03, Eugene Birukov wrote:
>> Just a wild guess - is this SIGHUP because stdin/stdout are broken? I.e. the
>> debugger closes its pty's on detach and that causes the signal?
>> What is the behavior on MAC?
>>
>>
>> To: lab...@google.com
>> Date: Wed, 30 Mar 2016 14:49:33 -0700
>> CC: lldb-dev@lists.llvm.org
>> Subject: Re: [lldb-dev] SBProcess::Detach kills target
>> From: lldb-dev@lists.llvm.org
>>
>>
>> Right, my bad. The problem was that when debugger detaches the stdio does
>> not go anywhere so I failed to see my printf.
>>
>> Still, is this how it is supposed to be? I naively assume that if we don't
>> send SIGHUP in attach scenario we should not send it in launch scenario too.
>>
>> Thanks,
>> Eugene
>>
>>> From: lab...@google.com
>>> Date: Wed, 30 Mar 2016 10:22:33 +0100
>>> Subject: Re: [lldb-dev] SBProcess::Detach kills target
>>> To: eugen...@hotmail.com
>>> CC: jing...@apple.com; lldb-dev@lists.llvm.org
>>>
>>> So I have made a small test program (which does nothing but spin in a
>>> loop), and indeed it is the SIGHUP that kills it after detach. If the
>>> test program blocks the signal, then it continues running even after
>>> detach:
>>> $ cat a.c
>>> #include
>>> #include
>>>
>>> int main() {
>>> signal(SIGHUP, SIG_IGN);
>>> for (;;) sleep(1);
>>> }
>>> $ cc a.c -g
>>> $ ps -A | grep a.out
>>> $ ~/ll/build/dbg/bin/lldb ./a.out
>>> (lldb) target create "./a.out"
>>> Current executable set to './a.out' (x86_64).
>>> (lldb) b 6
>>> Breakpoint 1: where = a.out`main + 19 at a.c:6, address =
>>> 0x00400590
>>> (lldb) r
>>> Process 13416 launched: './a.out' (x86_64)
>>> Process 13416 stopped
>>> * thread #1: tid = 13416, 0x00400590 a.out`main + 19 at a.c:6,
>>> name = 'a.out', stop reason = breakpoint 1.1
>>> frame #0: 0x00400590 a.out`main + 19 at a.c:6
>>> 3
>>> 4 int main() {
>>> 5 signal(SIGHUP, SIG_IGN);
>>> -> 6 for (;;) sleep(1);
>>> 7 }
>>> (lldb) detach
>>> Process 13416 detached
>>> (lldb) q
>>> $ ps -A | grep a.out
>>> 13416 ? 00:00:00 a.out
>>>
>>>
>>> On 29 March 2016 at 18:38, Eugene Birukov wrote:
I believe this is not SIGHUP on debugger exit. I am using my own C++
program
that calls into LLDB API. So, this program is still alive after calling
SBProcess::Detach() but the target dies. Also, the target intercepts
SIGHUP
to do cleanup before exiting. I put printf there, it was not hit.
>>> The fact whether your program is alive irrelevant. What matters is
>>> that by cleaning up the process structure, we will also close the
>>> master end of the pty used for inferior communication, and this is
>>> what causes the SIGHUP. For that reason you also cannot use a printf
>>> to do diagnostics as the output has nowhere to go. Note that lldb's
>>> behavior here will be different from gdb as gdb does not do stdio
>>> redirection, and has the inferior share the pty with the debugger (in
>>> which case your program will die when you close the terminal window).
>>>
I tried interactive LLDB, the target is not there:
Process 49145 stopped
* thread #1: tid = 49145, ..., stop reason = signal SIGSTOP
frame #0: 0x76a5bbed libc.so.6 at syscall-temp
Re: [lldb-dev] Review of API and remote packets
> On Mar 31, 2016, at 5:10 AM, Ravitheja Addepally via lldb-dev
> wrote:
>
> Hello all,
> I am currently working on enabling Intel (R) Processor Trace
> collection for lldb. I have done some previous discussions in this mailing
> list on this topic but just to summarize , the path we chose was to implement
> raw trace collection in lldb and the trace will be decoded outside LLDB. I
> wanted to expose this feature through the SB API's and for trace data
> transfer I wish to develop new communication packets. Now I want to get the
> new API's and packet specifications reviewed by the dev list. Please find the
> specification below ->
>
> lldb::SBError SBProcess::StartTrace(lldb::tid_t threadId, const SBTraceConfig
> &config)
> Start tracing for thread - threadId with trace configuration config.
> SBTraceConfig would contain the following fields-
> -> TraceType - ProcessorTrace, SoftwareTrace , any trace
> technology etc
> -> size of trace buffer
> -> size of meta data buffer
> Returns error in case starting trace was unsuccessful, which could occur
> by reasons such as
> picking non existent thread, target does not support TraceType selected
> etc.
If you are going to trace on a thread, we should be putting this API on
SBThread. Also we have other config type classes in our public API and we have
suffixed them with Options so SBTraceConfig should actually be SBTraceOptions.
Also don't bother using "const" on any public APIs since the mean nothing and
only cause issues. Why? All public classes usually contain a std::unique_ptr or
a std::shared_ptr to a private class that exists only within LLDB itself. The
"const" is just saying don't change my shared pointer, which doesn't actually
do anything.
lldb::SBError SBThread::StartTrace(SBTraceOptions &trace_options);
>
> lldb::SBError SBProcess::StopTrace(lldb::tid_t threadId)
> Stop tracing for thread - threadId. Tracing should be enabled already for
> thread, else error is returned.
This should be:
lldb::SBError SBThread::StopTrace();
One question: can there only be one kind of trace going on at the same time? If
we ever desire to support more than one at a time, we might need the above two
calls to be:
lldb::user_id_t SBThread::StartTrace(SBTraceOptions &trace_options,
lldb::SBError &error);
lldb::SBError SBThread::StopTrace(lldb::user_id_t trace_id);
The StartTrace could return a unique trace token that would need to be supplied
back to any other trace calls like the ones below.
> size_t SBProcess::DumpTraceData(lldb::tid_t threadId, void *buf, size_t size,
> SBError &sberror)
> Dump the raw trace data for threadId in buffer described by pointer buf
> and size. Tracing should be enabled already for thread else error
> is sent in sberror. The actual size of filled buffer is returned by API.
>
> size_t SBProcess::DumpTraceMetaData(lldb::tid_t threadId, void *buf, size_t
> size, SBError &sberror)
> Dump the raw trace meta data for threadId in buffer described by pointer
> buf and size. Tracing should be enabled already for thread
> else error is sent in sberror. The actual size of filled buffer is
> returned by API.
These would be on lldb::SBThread and remove the lldb::tid_t parameter, possibly
adding "lldb::user_id_t trace_id" as the first parameter.
The other way to do this is to create a lldb::SBTrace object. Then the APIs
become:
lldb::SBTrace SBThread::StartTrace(SBTraceOptions &trace_options, lldb::SBError
&error);
lldb::SBError SBTrace::StopTrace();
size_t SBTrace::GetData(void *buf, size_t size, SBError &sberror);
size_t SBTrace::GetMetaData(void *buf, size_t size, SBError &sberror);
lldb::SBThread SBTrace::GetThread();
>
> LLDB Trace Packet Specification
>
> QTrace:1:,,,
> Packet for starting tracing, where -
> -> threadid - stands for thread to trace
> -> type - Type of tracing to use, it will be like type of trace
> mechanism to use.
> For e.g ProcessorTrace, SoftwareTrace , any trace
> technology etc and if
> that trace is not supported by target error will be
> returned. In Future
> we can also add more parameters in the packet
> specification, which can be type specific
> and the server can parse them based on what type it read
> in the beginning.
> -> buffersize - Size for trace buffer
> -> metabuffersize - Size of Meta Data
If we design this, we should have the arguments be in key/value format:
> QTrace:1::;:;:;
Then this packet currently could be sent as:
QTrace:1:threadid:;type:;buffersize=;metabuffersize=;
This way if we ever need to add new key value pairs, we don't need to make a
new QTrace2 packet if the args ever change.
> QTrace:0:
> Stop tracing thread with threadid,{Trace needs to be started of-course
> else error}
again, this should be key/value pair encoded
Re: [lldb-dev] LLDB /w Windows and MinGW64
Ping... On Mon, Mar 28, 2016 at 10:19 PM, Eran Ifrah wrote: > Sorry, the current status is that lldb-server is no longer needed, however > the debuggee process hangs and the lldb.exe is "froze" (i.e. it does not > accept user input) > > Here is the backtrace: http://pastebin.com/mbLFgCA6 > I will try and get lldb built in debug mode for better debugging... but > this will take sometime as the generated files are too large to written to > the file system - (clang sources) > > I will teak the CMakeLists.txt files to fix this and will report back > In the meantime, if you have any more hints/tips - I will be happy to try > them here > > > Thanks > > > > On Mon, Mar 28, 2016 at 10:13 PM, Eran Ifrah wrote: > >> I was able to locate the problematic >> code: ProcessWindowsLive::Initialize() was not called due to wrong macros >> http://reviews.llvm.org/D18520 >> >> >> On Mon, Mar 28, 2016 at 9:31 PM, Eran Ifrah wrote: >> >>> Done. >>> >>> http://reviews.llvm.org/D18519 >>> >>> >>> On Mon, Mar 28, 2016 at 9:28 PM, Zachary Turner >>> wrote: >>> Almost, there's one more step. Click Create a New Revision on that screen, then give it a title and a description. For reviewers put zturner, and for subscribers put lldb-commits On Mon, Mar 28, 2016 at 11:20 AM Eran Ifrah wrote: > Is this what you meant: > http://reviews.llvm.org/differential/diff/51809/ > > Thanks > > On Mon, Mar 28, 2016 at 8:58 PM, Zachary Turner > wrote: > >> For the patch, can you create an account on reviews.llvm.org, and >> upload your patch there? This makes interactive reviewing / commenting >> much easier. Let me know if you need help getting that set up. >> >> On Mon, Mar 28, 2016 at 10:58 AM Zachary Turner >> wrote: >> >>> If you compile with MSVC or Clang-cl it wouldn't ask for >>> lldb-server. So most likely there is some code that is using #if >>> defined(_MSC_VER) when it should be using #if defined(LLVM_ON_WINDOWS). >>> >>> You'll have to hunt that down, but a good starting point might be to >>> put a breakpoint in ProcessWindowsLive::CreateInstance and then work >>> backwards to see why that isn't getting called (assuming it's not). >>> >>> On Mon, Mar 28, 2016 at 9:05 AM Eran Ifrah >>> wrote: >>> On Mon, Mar 28, 2016 at 6:56 PM, Zachary Turner >>> > wrote: > Patches welcome. If you can split it into independent pieces that > would be helpful, but it's not always possible. > > Patch is attached, I think you will find it quite straight forward - feel free to comment and send it back for revise > The NativeProcessProtocol error, that's the interface that > converts debugging events that occur on the inferior into packets > that can > be sent to the server, and vice versa. Since Windows doesn't > currently use > lldb server, this piece has never been written for Windows So this raises the question: how come lldb asks for it? (see my first emai inl this conversation) I would have build LLDB in debug mode, but it seems that MinGW as.exe fails to write some of the files "File too big" > > On Mon, Mar 28, 2016 at 8:41 AM Eran Ifrah > wrote: > >> On Mon, Mar 28, 2016 at 6:10 PM, Zachary Turner < >> ztur...@google.com> wrote: >> >>> I'm the main Windows maintainer, >> >> Hi >> >> >> >>> and while We've gotten things working pretty well on Windows, >>> our effort has been 100% on building with msvc and/or clang-cl. >>> Building >>> with mingw has a different set of pre processor defines and some >>> other >>> subtle differences, so it doesn't surprise me that things don't >>> work quite >>> right. >>> >>> I got it to compile (I have a big patch that I can send you if >> you are interested) >> mainly involves blocking code under __MINGW32__ and some updates >> to the various CMakeLists.txt and AddLLDB.cmake module files >> Some functions are missing in MinGW implementations (like gets_s >> and others :/) >> >> >> >>> You can try getting lldb-server to build and run under Windows, >>> or you can try to get it to use the non lldb server codepath on >>> MinGW, but >>> you may still run into some >> >> I got lldb-server to compile and run on Windows, however, it >> crashes immediately and the backtrace shows this: >> >> 0 0x00724615 >> >> lldb_private::NativeProcessProtocol::Launch(lldb_private::ProcessLaunchInfo&, >> lldb_private::
Re: [lldb-dev] SBProcess::Detach kills target
OK, I got the picture, thanks a lot!
> What is it that you are trying to do anyway?
Well, target termination during detach is unexpected, so my customers might get
confused. Fortunately I am in control of the target program too, so I'll just
ignore SIGHUP for the time being.
Thanks,Eugene
> From: lab...@google.com
> Date: Thu, 31 Mar 2016 09:16:06 +0100
> Subject: Re: [lldb-dev] SBProcess::Detach kills target
> To: eugen...@hotmail.com
> CC: lldb-dev@lists.llvm.org
>
> We are not sending the SIGHUP, it is automatically getting sent by the
> OS when the master end of the pty gets closed. The reason you are not
> seeing this in the attach scenario is that we do not intercept
> inferior stdio in this case (it's not possible, or desirable, since
> the process is already running). This is also the reason
> SBProcess.GetSTDOUT does not return anything in the attach scenario. I
> am not familiar with the details of the Mac implementation and I
> cannot tell you why is this not happening there.
> I guess one way to fix this would be to have a special mode of
> starting the inferior without a controlling terminal, but I am not
> sure if this would be a generally useful feature. What is it that you
> are trying to do anyway?
>
> pl
>
> On 30 March 2016 at 23:03, Eugene Birukov wrote:
> > Just a wild guess - is this SIGHUP because stdin/stdout are broken? I.e. the
> > debugger closes its pty's on detach and that causes the signal?
> > What is the behavior on MAC?
> >
> >
> > To: lab...@google.com
> > Date: Wed, 30 Mar 2016 14:49:33 -0700
> > CC: lldb-dev@lists.llvm.org
> > Subject: Re: [lldb-dev] SBProcess::Detach kills target
> > From: lldb-dev@lists.llvm.org
> >
> >
> > Right, my bad. The problem was that when debugger detaches the stdio does
> > not go anywhere so I failed to see my printf.
> >
> > Still, is this how it is supposed to be? I naively assume that if we don't
> > send SIGHUP in attach scenario we should not send it in launch scenario too.
> >
> > Thanks,
> > Eugene
> >
> >> From: lab...@google.com
> >> Date: Wed, 30 Mar 2016 10:22:33 +0100
> >> Subject: Re: [lldb-dev] SBProcess::Detach kills target
> >> To: eugen...@hotmail.com
> >> CC: jing...@apple.com; lldb-dev@lists.llvm.org
> >>
> >> So I have made a small test program (which does nothing but spin in a
> >> loop), and indeed it is the SIGHUP that kills it after detach. If the
> >> test program blocks the signal, then it continues running even after
> >> detach:
> >> $ cat a.c
> >> #include
> >> #include
> >>
> >> int main() {
> >> signal(SIGHUP, SIG_IGN);
> >> for (;;) sleep(1);
> >> }
> >> $ cc a.c -g
> >> $ ps -A | grep a.out
> >> $ ~/ll/build/dbg/bin/lldb ./a.out
> >> (lldb) target create "./a.out"
> >> Current executable set to './a.out' (x86_64).
> >> (lldb) b 6
> >> Breakpoint 1: where = a.out`main + 19 at a.c:6, address =
> >> 0x00400590
> >> (lldb) r
> >> Process 13416 launched: './a.out' (x86_64)
> >> Process 13416 stopped
> >> * thread #1: tid = 13416, 0x00400590 a.out`main + 19 at a.c:6,
> >> name = 'a.out', stop reason = breakpoint 1.1
> >> frame #0: 0x00400590 a.out`main + 19 at a.c:6
> >> 3
> >> 4 int main() {
> >> 5 signal(SIGHUP, SIG_IGN);
> >> -> 6 for (;;) sleep(1);
> >> 7 }
> >> (lldb) detach
> >> Process 13416 detached
> >> (lldb) q
> >> $ ps -A | grep a.out
> >> 13416 ? 00:00:00 a.out
> >>
> >>
> >> On 29 March 2016 at 18:38, Eugene Birukov wrote:
> >> > I believe this is not SIGHUP on debugger exit. I am using my own C++
> >> > program
> >> > that calls into LLDB API. So, this program is still alive after calling
> >> > SBProcess::Detach() but the target dies. Also, the target intercepts
> >> > SIGHUP
> >> > to do cleanup before exiting. I put printf there, it was not hit.
> >> The fact whether your program is alive irrelevant. What matters is
> >> that by cleaning up the process structure, we will also close the
> >> master end of the pty used for inferior communication, and this is
> >> what causes the SIGHUP. For that reason you also cannot use a printf
> >> to do diagnostics as the output has nowhere to go. Note that lldb's
> >> behavior here will be different from gdb as gdb does not do stdio
> >> redirection, and has the inferior share the pty with the debugger (in
> >> which case your program will die when you close the terminal window).
> >>
> >> >
> >> > I tried interactive LLDB, the target is not there:
> >> >
> >> > Process 49145 stopped
> >> > * thread #1: tid = 49145, ..., stop reason = signal SIGSTOP
> >> > frame #0: 0x76a5bbed libc.so.6 at syscall-template.S:81
> >> > (lldb) detach
> >> > Process 49145 detached
> >> > (lldb) q
> >> > eugene@EUGENEBI-L1:~/tmp$ ps
> >> > PID TTY TIME CMD
> >> > 30714 pts/17 00:00:00 bash
> >> > 49259 pts/17 00:00:00 ps
> >> Note that the inferior will not show up here even if it exists, as ps
> >> will only list the processes with the same tty, but at this point the
> >> inferior process has no tty.
Re: [lldb-dev] LLDB /w Windows and MinGW64
I will have another look tomorrow. On Thu, Mar 31, 2016 at 11:56 AM Eran Ifrah wrote: > Ping... > > On Mon, Mar 28, 2016 at 10:19 PM, Eran Ifrah wrote: > >> Sorry, the current status is that lldb-server is no longer needed, >> however the debuggee process hangs and the lldb.exe is "froze" (i.e. it >> does not accept user input) >> >> Here is the backtrace: http://pastebin.com/mbLFgCA6 >> I will try and get lldb built in debug mode for better debugging... but >> this will take sometime as the generated files are too large to written to >> the file system - (clang sources) >> >> I will teak the CMakeLists.txt files to fix this and will report back >> In the meantime, if you have any more hints/tips - I will be happy to try >> them here >> >> >> Thanks >> >> >> >> On Mon, Mar 28, 2016 at 10:13 PM, Eran Ifrah >> wrote: >> >>> I was able to locate the problematic >>> code: ProcessWindowsLive::Initialize() was not called due to wrong macros >>> http://reviews.llvm.org/D18520 >>> >>> >>> On Mon, Mar 28, 2016 at 9:31 PM, Eran Ifrah >>> wrote: >>> Done. http://reviews.llvm.org/D18519 On Mon, Mar 28, 2016 at 9:28 PM, Zachary Turner wrote: > Almost, there's one more step. Click Create a New Revision on that > screen, then give it a title and a description. For reviewers put > zturner, > and for subscribers put lldb-commits > > On Mon, Mar 28, 2016 at 11:20 AM Eran Ifrah > wrote: > >> Is this what you meant: >> http://reviews.llvm.org/differential/diff/51809/ >> >> Thanks >> >> On Mon, Mar 28, 2016 at 8:58 PM, Zachary Turner >> wrote: >> >>> For the patch, can you create an account on reviews.llvm.org, and >>> upload your patch there? This makes interactive reviewing / commenting >>> much easier. Let me know if you need help getting that set up. >>> >>> On Mon, Mar 28, 2016 at 10:58 AM Zachary Turner >>> wrote: >>> If you compile with MSVC or Clang-cl it wouldn't ask for lldb-server. So most likely there is some code that is using #if defined(_MSC_VER) when it should be using #if defined(LLVM_ON_WINDOWS). You'll have to hunt that down, but a good starting point might be to put a breakpoint in ProcessWindowsLive::CreateInstance and then work backwards to see why that isn't getting called (assuming it's not). On Mon, Mar 28, 2016 at 9:05 AM Eran Ifrah wrote: > On Mon, Mar 28, 2016 at 6:56 PM, Zachary Turner < > ztur...@google.com> wrote: > >> Patches welcome. If you can split it into independent pieces that >> would be helpful, but it's not always possible. >> >> Patch is attached, I think you will find it quite straight > forward - feel free to comment and send it back for revise > > > >> The NativeProcessProtocol error, that's the interface that >> converts debugging events that occur on the inferior into packets >> that can >> be sent to the server, and vice versa. Since Windows doesn't >> currently use >> lldb server, this piece has never been written for Windows > > So this raises the question: how come lldb asks for it? (see my > first emai inl this conversation) > I would have build LLDB in debug mode, but it seems that MinGW > as.exe fails to write some of the files "File too big" > > > >> >> On Mon, Mar 28, 2016 at 8:41 AM Eran Ifrah >> wrote: >> >>> On Mon, Mar 28, 2016 at 6:10 PM, Zachary Turner < >>> ztur...@google.com> wrote: >>> I'm the main Windows maintainer, >>> >>> Hi >>> >>> >>> and while We've gotten things working pretty well on Windows, our effort has been 100% on building with msvc and/or clang-cl. Building with mingw has a different set of pre processor defines and some other subtle differences, so it doesn't surprise me that things don't work quite right. I got it to compile (I have a big patch that I can send you if >>> you are interested) >>> mainly involves blocking code under __MINGW32__ and some updates >>> to the various CMakeLists.txt and AddLLDB.cmake module files >>> Some functions are missing in MinGW implementations (like gets_s >>> and others :/) >>> >>> >>> You can try getting lldb-server to build and run under Windows, or you can try to get it to use the non lldb server codepath on MinGW, but you may still run into some >>> >>> I got lldb-server to compile and
