krytarowski added inline comments.
================ Comment at: unittests/tools/lldb-server/inferior/thread_inferior.cpp:21 + + LLVM_BUILTIN_DEBUGTRAP; + delay = false; ---------------- 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)`? https://reviews.llvm.org/D32930 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
