zturner added inline comments.
================ Comment at: unittests/tools/lldb-server/inferior/thread_inferior.cpp:21 + + LLVM_BUILTIN_DEBUGTRAP; + delay = false; ---------------- labath wrote: > krytarowski wrote: > > labath wrote: > > > krytarowski wrote: > > > > jmajors wrote: > > > > > krytarowski wrote: > > > > > > jmajors wrote: > > > > > > > zturner wrote: > > > > > > > > This will work on MSVC and presumably clang. I'm not sure > > > > > > > > about gcc. Is that sufficient for your needs? Do you know if > > > > > > > > gcc has the `__builtin_debugtrap` intrinsic? > > > > > > > Do we use gcc to build/test lldb? If not, then it shouldn't be an > > > > > > > issue. If we ever change our compiler of choice, we can always > > > > > > > change this to match. > > > > > > Yes, we use and support GCC with libstdc++ to build LLDB including > > > > > > tests. At least on NetBSD. > > > > > Is there a gcc equivalent, that I could wrap in some #ifdefs? > > > > No, there is no equivalent and I'm trying to convince that we should > > > > not try to use this `__builtin_debugtrap()` in the code. We should ask > > > > the debugger to set and handle the trap. > > > > > > > > Otherwise we will need to handle this on per-cpu and per-os matrix. In > > > > the SPARC/NetBSD example we would need to ask the debugger to set PC > > > > after the trap manually. > > > The thing with the lldb-server tests is that there is no "debugger" which > > > can set the figure out where to set the breakpoint. Lldb-server operates > > > at a much lower level, and it knows nothing about dwarf, or even symbol > > > tables, and I think the tests shouldn't either (mainly to keep the tests > > > more targetted, but also because it would be quite tricky to wire that up > > > at this level). The existing lldb-server tests don't do debug info > > > parsing either. > > > > > > BTW, this test doesn't actually need the int3 breakpoint for its work -- > > > all we need is for the inferior to stop so that the debugger can take a > > > look at this state. Any stopping event will do the trick, and the most > > > "portable" would probably be dereferencing a null pointer. > > > > > > However, we will get back to this soon enough, when we start talking > > > about breakpoint-setting tests. Since the client doesn't know anything > > > about debug info, the best way to figure out where to set a breakpoint is > > > for the inferior to tell us. The way existing lldb-server tests do that > > > is via printf, but that has some issues (intercepting stdio is hard or > > > impossible on windows and stdio comes asynchronously on linux so it is > > > hard to write race-free tests). The most reliable way I came up for that > > > was to put that value in a register. Now this requires a bit of assembly > > > (eg., `movq %rax, $function_I_want_to_break_in; int3` in x86 case), but > > > that little snippet can be tucked away in a utility function (plus a > > > similar utility function on the recieving side to read out the value) and > > > noone has to look at it again, and the rest of the test can be > > > architecture-independent. > > > > > > The assembly will obviously be architecture-dependent, but I don't think > > > we will really need an OS dimension. I am not sure if we currently > > > support on os where the PC fixup would be necessary, but even if we do, > > > the implementation of that would be quite simple. > > > > > > I am open to other ideas on how to pass information between the inferior > > > and the test though. > > Can we go for `raise(SIGTRAP)`? > Doesn't work on windows (so it is not more portable than null dereference) > and it has no payload (so you cannot use it for passing data to the test) :) Just use `LLVM_BUILTIN_TRAP` or a null pointer dereference, so it works everywhere. https://reviews.llvm.org/D32930 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
