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