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

[Todd Fiala via lldb-dev]

On Thu, Aug 27, 2015 at 3:01 PM, via lldb-dev <lldb-dev at lists.llvm.org>
wrote:

> On Thu, Aug 27, 2015 at 05:05:23PM +0000, Zachary Turner via lldb-dev
> wrote:
> > Well I'm xfailing it for now, but this other method seems kind of hackish
> > to me because it means the inferior and the debugger have to coordinate
> > with each other, which means the test has to know about the executable
> and
> > the executable has to know about the test.  I'd rather remove one
> direction
> > of this coupling.
> >
> > Eventually my plan is to introduce a test_util.a which all of the test
> > executables link against.  We can provide a platform-independent
> > wait_for_debugger_to_attach() method here that just does the right thing
> on
> > all platforms.  This way the tests can be written without having to do
> this
> > funny business :)
>
> What about fixing lldb to prefer to debug via launch instead of attach
> depending on the platform???
>
>
The largest section of code getting debugged in production on the Apple
side is in attached scenarios (often by requirement), so reducing attach
test coverage isn't something I think we'd want to do at least on Apple
platforms.


> I don't see how you could write a wait_for_debugger_to_attach() that would
> work reliably.
>

What about building a helper method that we mandate main() call for
attach-enabled tests, that loops in a known function and has an exit
scenario that the debugger can control.  Then, on attach, we set a
breakpoint on something (which can be shared out several different ways,
either by variable address lookup if we have symbols, or could be added to
the environment by the helper method, etc.)  Then the protocol becomes:

The lldb test would do something like this:
1. attach to process
2. collect breakpoint information, which may require the inferior to be
running more if we attach before main has even fired.  No worries there,
though.
3. set breakpoint at collected spot.
4. when synchronization breakpoint is hit, we now know we're in a good
startup spot.

And if a test might be used both in an attach-synchronous mode and not
attached at all, that helper method could be controlled (again perhaps by
environment variable or something else) to skip doing the waiting step if
it doesn't expect to get attached to by the debugger.

All that could be put behind helpers on the lldb test side to more or less
hide all traces of it.  Test inferiors would need a call to a helper method
that could be fully defined in a header to simplify getting that code
brought in.

That would eliminate races in attach tests by creating an agreed
synchronization point.

-Todd

_______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>



-- 
-Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150828/86808cea/attachment.html>