Re: [lldb-dev] How does attach work on non-Windows?

2015-08-31 Thread Greg Clayton via lldb-dev 
So a few things:

1 - on MacOSX we can reliably launch a process via posix_spawn() with a flag 
set that sets the process to stop at __dyld_start which is the first 
instruction in the program. So our launch then attach always works reliably 
because when we launch the process set set this posix_spawn() flag.

2 - on linux I believe this is solved by doing a manual fork(), sync(), exec().

3 - on windows we have a sync problem for the launch first then attach due to 
this extra thread. Is this the case?

Seems like you should be able to launch with Use the CreateProcess() function, 
set CREATE_SUSPENDED and then attach no?

I would rather not solve this problem that is windows only by requiring that 
all test suite functions link to a .a file. We should be able to launch a 
process and debug it using the launch then attach method that is used by our 
platform.

Greg



> On Aug 27, 2015, at 4:04 PM, via lldb-dev  wrote:
> 
> On Thu, Aug 27, 2015 at 10:17:24PM +, Zachary Turner wrote:
>> In what instances do you think it wouldn't work?  At least on Windows it's
>> trivial.  Jim provided some code that would work on OSX, and someone else
>> provided a method earlier in the thread that should work for Linux.  What
>> are the specific reliability concerns you have?
> 
> I'm basing this off our own experiences - we use a similar method to
> test Android and iOS platforms, and they work most of the time, but fail
> randomly, about once every 25 runs, because one of the 50 or so test
> cases couldn't sync up with the debug server on the device.  Do other
> people see similar problems?
> 
> If you're running the tests natively, I bet you'll be fine.
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_lldb-2Ddev=BQIGaQ=eEvniauFctOgLOKGJOplqw=e494ZqshU04UaasD49FjA8X8-41XrPe2DEAUCC4uIBA=rcCO6AJ3AdDHg5mYGyuAIclByBVrIHeeEMSbtprurNY=7I8Xb9uQ5clKv1lA-TQgZ6iHALia6UDWoINpajCOoQ8=
>  

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

Re: [lldb-dev] How does attach work on non-Windows?

2015-08-31 Thread Greg Clayton via lldb-dev 
Or is this just a problem with a bad test? Are we telling LLDB to launch the 
test and LLDB is doing the launch + attach in the windows platform and that is 
what is hosing up the attach? Or is this a flawed test where the test just 
manually launches the process with no hopes of syncing with the process we are 
attaching to?

> On Aug 31, 2015, at 3:16 PM, Greg Clayton via lldb-dev 
>  wrote:
> 
> So a few things:
> 
> 1 - on MacOSX we can reliably launch a process via posix_spawn() with a flag 
> set that sets the process to stop at __dyld_start which is the first 
> instruction in the program. So our launch then attach always works reliably 
> because when we launch the process set set this posix_spawn() flag.
> 
> 2 - on linux I believe this is solved by doing a manual fork(), sync(), 
> exec().
> 
> 3 - on windows we have a sync problem for the launch first then attach due to 
> this extra thread. Is this the case?
> 
> Seems like you should be able to launch with Use the CreateProcess() 
> function, set CREATE_SUSPENDED and then attach no?
> 
> I would rather not solve this problem that is windows only by requiring that 
> all test suite functions link to a .a file. We should be able to launch a 
> process and debug it using the launch then attach method that is used by our 
> platform.
> 
> Greg
> 
> 
> 
>> On Aug 27, 2015, at 4:04 PM, via lldb-dev  wrote:
>> 
>> On Thu, Aug 27, 2015 at 10:17:24PM +, Zachary Turner wrote:
>>> In what instances do you think it wouldn't work?  At least on Windows it's
>>> trivial.  Jim provided some code that would work on OSX, and someone else
>>> provided a method earlier in the thread that should work for Linux.  What
>>> are the specific reliability concerns you have?
>> 
>> I'm basing this off our own experiences - we use a similar method to
>> test Android and iOS platforms, and they work most of the time, but fail
>> randomly, about once every 25 runs, because one of the 50 or so test
>> cases couldn't sync up with the debug server on the device.  Do other
>> people see similar problems?
>> 
>> If you're running the tests natively, I bet you'll be fine.
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_lldb-2Ddev=BQIGaQ=eEvniauFctOgLOKGJOplqw=e494ZqshU04UaasD49FjA8X8-41XrPe2DEAUCC4uIBA=rcCO6AJ3AdDHg5mYGyuAIclByBVrIHeeEMSbtprurNY=7I8Xb9uQ5clKv1lA-TQgZ6iHALia6UDWoINpajCOoQ8=
>>  
> 
> ___
> 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] How does attach work on non-Windows?

2015-08-31 Thread Zachary Turner via lldb-dev 
I think it's mostly a problem of tests.  Basically we have tests which are
written in such a way that the inferior and the debugger need to reach a
synchronization point before the test can proceed to test what it wants to
test.

On Mon, Aug 31, 2015 at 4:08 PM Greg Clayton  wrote:

> Or is this just a problem with a bad test? Are we telling LLDB to launch
> the test and LLDB is doing the launch + attach in the windows platform and
> that is what is hosing up the attach? Or is this a flawed test where the
> test just manually launches the process with no hopes of syncing with the
> process we are attaching to?
>
> > On Aug 31, 2015, at 3:16 PM, Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > So a few things:
> >
> > 1 - on MacOSX we can reliably launch a process via posix_spawn() with a
> flag set that sets the process to stop at __dyld_start which is the first
> instruction in the program. So our launch then attach always works reliably
> because when we launch the process set set this posix_spawn() flag.
> >
> > 2 - on linux I believe this is solved by doing a manual fork(), sync(),
> exec().
> >
> > 3 - on windows we have a sync problem for the launch first then attach
> due to this extra thread. Is this the case?
> >
> >  Seems like you should be able to launch with Use the CreateProcess()
> function, set CREATE_SUSPENDED and then attach no?
> >
> > I would rather not solve this problem that is windows only by requiring
> that all test suite functions link to a .a file. We should be able to
> launch a process and debug it using the launch then attach method that is
> used by our platform.
> >
> > Greg
> >
> >
> >
> >> On Aug 27, 2015, at 4:04 PM, via lldb-dev 
> wrote:
> >>
> >> On Thu, Aug 27, 2015 at 10:17:24PM +, Zachary Turner wrote:
> >>> In what instances do you think it wouldn't work?  At least on Windows
> it's
> >>> trivial.  Jim provided some code that would work on OSX, and someone
> else
> >>> provided a method earlier in the thread that should work for Linux.
> What
> >>> are the specific reliability concerns you have?
> >>
> >> I'm basing this off our own experiences - we use a similar method to
> >> test Android and iOS platforms, and they work most of the time, but fail
> >> randomly, about once every 25 runs, because one of the 50 or so test
> >> cases couldn't sync up with the debug server on the device.  Do other
> >> people see similar problems?
> >>
> >> If you're running the tests natively, I bet you'll be fine.
> >> ___
> >> lldb-dev mailing list
> >> lldb-dev@lists.llvm.org
> >>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_lldb-2Ddev=BQIGaQ=eEvniauFctOgLOKGJOplqw=e494ZqshU04UaasD49FjA8X8-41XrPe2DEAUCC4uIBA=rcCO6AJ3AdDHg5mYGyuAIclByBVrIHeeEMSbtprurNY=7I8Xb9uQ5clKv1lA-TQgZ6iHALia6UDWoINpajCOoQ8=
> >
> > ___
> > 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] How does attach work on non-Windows?

2015-08-26 Thread Jim Ingham via lldb-dev 
There is a way on OS X.  There is a sysctl that will give you information on 
the current process state, and one of the bits you get back says whether the 
process is being traced.  sysctl's are a generic UNIX thing, but I don't know 
if the bit OS X uses is shared with other Unix's.

Jim

 On Aug 26, 2015, at 2:20 PM, Zachary Turner via lldb-dev 
 lldb-dev@lists.llvm.org wrote:
 
 Slightly related, but do other platforms have a way to check from an inferior 
 if a debugger is present?
 
 We need to do this frequently from the test inferiors, and I see lots of 
 different approaches used in the test programs, none of which work correctly 
 on Windows.
 
 On Wed, Aug 26, 2015 at 2:09 PM Zachary Turner ztur...@google.com wrote:
 On Windows, when we attach to process, we basically invoke a system call 
 which tells the kernel to kick off the process necessary for a debugger to be 
 able to communicate with the process.
 
 The end result of all this is that eventually the OS itself will generate a 
 breakpoint in the inferior by injecting an additional thread into the 
 inferior and breaking on that thread.
 
 LLDB picks this up, and the result is that LLDB stops and waits for the user 
 to continue the inferior just as it would with any other breakpoint, and if 
 you were to get a backtrace you might see something like this:
 
 looking at: Stack traces for SBProcess: pid = 12588, state = stopped, threads 
 = 2, executable = test_with_dwarf_and_attach_to_process_with_id_api
 Stack trace for thread id=0x3428 name=None queue=None stop reason=none
   frame #0: 0x ntdll.dll`DbgBreakPoint + 1
 
 Stack trace for thread id=0x4314 name=None queue=None stop reason=none
   frame #0: 0x0077908c2c None`None + -18446744071703589843
 
 
 My question is: Do other platforms have this concept of an OS-generated 
 breakpoint?  Or when you attach to the process, would the first breakpoint 
 opcode encountered by the inferior be one which was created by the user 
 through some command from the debugger?
 
 This creates a problem for some of our tests, because we have this extra 
 breakpoint that is messing up the stack frame expectations unless we issue a 
 manual continue first to get past the initial breakpoitn and to the first 
 user breakpoint.
 ___
 lldb-dev mailing list
 lldb-dev@lists.llvm.org
 https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_lldb-2Ddevd=BQIGaQc=eEvniauFctOgLOKGJOplqwr=aTCVT7yw0RLKhx7ZXY2faboS3m1dhXpYF-Av4XoSGMUm=VvFNLC1Qe6kBmEoVqGF9NZIVrDnFQZBDYfsUdMRn1aEs=9o1ODu6v5nQisbSZVZpKU56ZDygZTcK6a_1juRJLhise=
  

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

Re: [lldb-dev] How does attach work on non-Windows?

2015-08-26 Thread Jim Ingham via lldb-dev 
On OS X and most Unixes, you call ptrace(pid, PT_ATTACH) or some procfs call to 
initiate the attach, and then wait on the pid until it comes back with a 
SIGSTOP signal when the attach is completed.  How the wait is done differs from 
system to system, but this is the general model.  I have not heard of a UNIX 
that uses actual trap instructions placed by the kernel in the process to stop 
it.

Jim

 On Aug 26, 2015, at 2:09 PM, Zachary Turner via lldb-dev 
 lldb-dev@lists.llvm.org wrote:
 
 On Windows, when we attach to process, we basically invoke a system call 
 which tells the kernel to kick off the process necessary for a debugger to be 
 able to communicate with the process.
 
 The end result of all this is that eventually the OS itself will generate a 
 breakpoint in the inferior by injecting an additional thread into the 
 inferior and breaking on that thread.
 
 LLDB picks this up, and the result is that LLDB stops and waits for the user 
 to continue the inferior just as it would with any other breakpoint, and if 
 you were to get a backtrace you might see something like this:
 
 looking at: Stack traces for SBProcess: pid = 12588, state = stopped, threads 
 = 2, executable = test_with_dwarf_and_attach_to_process_with_id_api
 Stack trace for thread id=0x3428 name=None queue=None stop reason=none
   frame #0: 0x ntdll.dll`DbgBreakPoint + 1
 
 Stack trace for thread id=0x4314 name=None queue=None stop reason=none
   frame #0: 0x0077908c2c None`None + -18446744071703589843
 
 
 My question is: Do other platforms have this concept of an OS-generated 
 breakpoint?  Or when you attach to the process, would the first breakpoint 
 opcode encountered by the inferior be one which was created by the user 
 through some command from the debugger?
 
 This creates a problem for some of our tests, because we have this extra 
 breakpoint that is messing up the stack frame expectations unless we issue a 
 manual continue first to get past the initial breakpoitn and to the first 
 user breakpoint.
 ___
 lldb-dev mailing list
 lldb-dev@lists.llvm.org
 https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_lldb-2Ddevd=BQIGaQc=eEvniauFctOgLOKGJOplqwr=aTCVT7yw0RLKhx7ZXY2faboS3m1dhXpYF-Av4XoSGMUm=L-3KeVaOuHZA0PFZErpqOUVyPGhnBc0qTlAnlY2nL8As=dSTTA6Jqz1P1PNsAHJN-99X-FdcVufV3UTWsB3Defx0e=
  

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