This is cut and pasted from an email reply as it's not showing up after over 2 hours...
Missing testcase for "li a0, foo".
I'm not seeing any problems with this.
If any of our lldb_private::Process subclasses handle this already, then we need a new virtual function on lldb_private::Process like:
So the question still remains: does this need to be done when debugging with debugserver or lldb-server? I can't remember if memory write works around breakpoint opcodes in debugserver and/or lldb-server. If it does, then this code is only needed for targets that don't work around software breakpoints.
All good now. Thanks
I like that we can customize the command substitutions and the way we dump internal state in this test mode. This offers some added flexibility over the batch mode, IMO. LGTM, thanks!
Change ForEach return type (bool -> void)
This test doesn't work if threads are not scheduled as expected: http://lab.llvm.org:8011/builders/openmp-gcc-x86_64-linux-debian/builds/58
I think in that case a worker thread started before the second master which makes sense as there is no synchronization between the two initial threads. We should be able to fix this by either starting a serialized region or calling an API function and putting an OMPT_WAIT before the real parallel region. Thoughts?
This test deliberately compiles without -g, so the variable should not be in the debug info.
It seems a little counter-intuitive for embedded source to have a filename, but I guess that's so the debugger has a familiar-looking handle to refer to it?
This test deliberately compiles without -g, so the variable should not be in the debug info. On non-windows systems we're expected to pick up the name from the symbol table. Is there such a thing on windows as well? Maybe you need to lookup the symbol as _conflicting_symbol ?
A constructor would also mitigate the dlopen issue (see the comment before the interceptor). Not that we've seen this issue in the wild.
Thanks for the feedback.