Commit Graph

17 Commits

Author SHA1 Message Date
Pavel Labath 3bea7306e8 [lldb] Fix compilation with gcc-6.5
This fixes (works around) two errors with gcc-6.5.
- in the RegisterContext_x86 files, gcc is unable to synthesize a
  default constructor -- it thinks it needs to initialize the virtual
  base class, even though said classes are abstract. I fix that by
  providing a dummy constructor.
- In ReproducerInstrumentationTest, it is not able to deduce that the
  TestingRegistry class is movable (it contains a map of unique
  pointers). I change the type from Optional<TestingRegistry> to
  unique_ptr<TestingRegistry), so that moving is not required
  (copying/moving a polymorphic type is not a very good idea in any
  case).
2021-04-01 08:44:50 +02:00
Jonas Devlieghere ac25e8628c [lldb] Deal gracefully with concurrency in the API instrumentation.
Prevent lldb from crashing when multiple threads are concurrently
accessing the SB API with reproducer capture enabled.

The API instrumentation records both the input arguments and the return
value, but it cannot block for the duration of the API call. Therefore
we introduce a sequence number that allows to to correlate the function
with its result and add locking to ensure those two parts are emitted
atomically.

Using the sequence number, we can detect situations where the return
value does not succeed the function call, in which case we print an
error saying that concurrency is not (currently) supported. In the
future we might attempt to be smarter and read ahead until we've found
the return value matching the current call.

Differential revision: https://reviews.llvm.org/D92820
2020-12-10 09:37:49 -08:00
Jonas Devlieghere e687aa8282 [lldb/Reproducers] Fix passive replay for (char*, size_t) functions.
Several SB API functions return strings using (char*, size_t) output
arguments. During capture, we serialize an empty string for the char*
because the memory can be uninitialized.

During active replay, we have custom replay redirects that ensure that
we don't override the buffer from which we're reading, but rather write
to a buffer on the heap with the given length. This is sufficient for
the active reproducer use case, where we only care about the side
effects of the API calls, not the values actually returned.

This approach does not not work for passive replay because here we
ignore all the incoming arguments, and re-execute the current function
with the arguments deserialized from the reproducer. This means that
these function will update the deserialized copy of the arguments,
rather than whatever was passed in by the SWIG wrapper.

To solve this problem, this patch extends the reproducer instrumentation
to handle this special case for passive replay. We nog ignore the
replayer in the registry and the incoming char pointer, and instead
reinvoke the current method on the deserialized class, and populate the
output argument.

Differential revision: https://reviews.llvm.org/D77759
2020-04-20 13:26:11 -07:00
Jonas Devlieghere e128d53895 [lldb/Test] Don't friend std::make_unique
This wasn't a great idea to begin with, as you can't really rely on the
implementation, but since it also doesn't work with MSVC I've just made
the ctors public.
2020-04-20 11:48:52 -07:00
Jonas Devlieghere 950a8aa165 [lldb/Reproducers] Support new replay mode: passive replay
Support passive replay as proposed in the RFC [1] on lldb-dev and
described in more detail on the lldb website [2].

This patch extends the LLDB_RECORD macros to re-invoke the current
function with arguments deserialized from the reproducer. This relies on
the function being called in the exact same order as during replay. It
uses the same mechanism to toggle the API boundary as during recording,
which guarantees that only boundary crossing calls are replayed.

Another major change is that before this patch we could ignore the
result of an API call, because we only cared about the observable
behavior. Now we need to be able to return the replayed result to the
SWIG bindings.

We reuse a lot of the recording infrastructure, which can be a little
confusing. We kept the existing naming to limit the amount of churn, but
might revisit that in a future patch.

[1] http://lists.llvm.org/pipermail/lldb-dev/2020-April/016100.html
[2] https://lldb.llvm.org/resources/reproducers.html

Differential revision: https://reviews.llvm.org/D77602
2020-04-20 09:41:40 -07:00
Jonas Devlieghere cc220d4031 [lldb/Test] Use RAII for reproducer instrumentation data in unittest.
Use a RAII object to manage the lifetime of the reproducer
instrumentation data.
2020-04-14 14:46:39 -07:00
Jonas Devlieghere f78fcd6906 [lldb/Test] Rewrite ReproducerInstrumentationTest
The instrumentation unit tests' current implementation uses global
variables to track constructor calls for the instrumented classes during
replay. This is suboptimal because it indirectly relies on how the
reproducer instrumentation is implemented. I found out when adding
support for passive replay and the test broke because we made an extra
(temporary) copy of the instrumented objects.

Additionally, the old approach wasn't very self-explanatory. It took me
a bit of time to understand why we were expecting the number of objects
in the test.

This patch rewrites the test and uses the index-to-object-mapping to
verify the objects created during replay. You can now specify the
expected objects, in order, and whether they should be valid or not. I
find that it makes the tests much easier to understand. More
importantly, this approach is resilient to implementation detail changes
in the instrumentation.
2020-04-10 16:50:44 -07:00
Jonas Devlieghere c62ffb1b19 [lldb/Reproducers] Include string length in string (de)serialization.
This allows us to differentiate between an empty string and a nullptr.

(cherry picked from commit 53e206284fa715886020d6a5553bf791582850a3)
2020-01-31 17:40:49 -08:00
Jonas Devlieghere 91f863be4f [lldb/Reproducers] Add unittest for char** (de)serializer 2020-01-29 17:16:31 -08:00
Raphael Isemann 808142876c [lldb][NFC] Fix all formatting errors in .cpp file headers
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).

This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).

Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D73258
2020-01-24 08:52:55 +01:00
Alexandre Ganea 18ca8a2233 Silence 'warning C4305: 'initializing': truncation from 'double' to 'float'' with MSVC 19.16.27021.1 (VS2017 15.9.12)
llvm-svn: 362437
2019-06-03 18:46:30 +00:00
Jonas Devlieghere fad8fb8032 [Reproducers] Fix reproducer unittest
I think the recent change to flush the SB API recording uncovered a real
issue on the Windows bot. Although I couldn't make much sense of the
error message "unknown file: error: SEH exception with code 0x3221225477
thrown in the test body.", it prompted me to look at the test. In the
unit test we were recording during replay, which is obviously not
correct. I think we didn't see this issue before because we flushed once
after the recording was done. This patch unsets the recording  logic
during the replay part of the test.

Hopefully this fixed the Windows bot.

llvm-svn: 360298
2019-05-08 22:59:35 +00:00
Jonas Devlieghere 306809f292 [Reproducers] Capture return values of functions returning by ptr/ref
For some reason I had convinced myself that functions returning by
pointer or reference do not require recording their result. However,
after further considering I don't see how that could work, at least not
with the current implementation. Interestingly enough, the reproducer
instrumentation already (mostly) accounts for this, though the
lldb-instr tool did not.

This patch adds the missing macros and updates the lldb-instr tool.

Differential revision: https://reviews.llvm.org/D60178

llvm-svn: 357639
2019-04-03 21:31:22 +00:00
Michal Gorny ae211ece6a [lldb] [Reproducer] Move SBRegistry registration into declaring files
Move SBRegistry method registrations from SBReproducer.cpp into files
declaring the individual APIs, in order to reduce the memory consumption
during build and improve maintainability.  The current humongous
SBRegistry constructor exhausts all memory on a NetBSD system with 4G
RAM + 4G swap, therefore making it impossible to build LLDB.

Differential Revision: https://reviews.llvm.org/D59427

llvm-svn: 356481
2019-03-19 17:13:13 +00:00
Jonas Devlieghere e0ccb403c2 [unittest] Fix missing user-provided default constructor
error: default initialization of an object of const type 'const Pod'
without a user-provided default constructor

llvm-svn: 354602
2019-02-21 17:18:06 +00:00
Jonas Devlieghere 58947cf854 [Reproducers] SBReproducer framework: Capture & Replay
This is part two of the reproducer instrumentation framework. It
contains the code to capture and replay function calls. The main user of
this framework will be the SB API layer.

For all the details refer to the RFC on the mailing list:
http://lists.llvm.org/pipermail/lldb-dev/2019-January/014530.html

Differential revision: https://reviews.llvm.org/D56322

llvm-svn: 353324
2019-02-06 18:57:42 +00:00
Jonas Devlieghere 494fd8f84f [Reproducers] Instrumentation Framework: Serialization
This is the is serialization/deserialization part of the reproducer
instrumentation framework.

For all the details refer to the RFC on the mailing list:
http://lists.llvm.org/pipermail/lldb-dev/2019-January/014530.html

Differential revision: https://reviews.llvm.org/D57714

llvm-svn: 353195
2019-02-05 18:46:36 +00:00