krytarowski added inline comments.
================ Comment at: unittests/tools/lldb-server/inferior/thread_inferior.cpp:21 + + LLVM_BUILTIN_DEBUGTRAP; + delay = false; ---------------- zturner wrote: > 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. I'm for NULL pointer dereference. ``` volatile char *p = NULL; *p = 'a'; ``` or similar. https://reviews.llvm.org/D32930 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
