[Lldb-commits] [PATCH] D32930: New framework for lldb client-server communication tests.

[Kamil Rytarowski via Phabricator via lldb-commits]

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