Commit Graph

979 Commits

Author SHA1 Message Date
Muhammad Omair Javaid 8ef23a39ca [LLDB] Skip TestDataFormatterStdUniquePtr.py on arm/linux
TestDataFormatterStdUniquePtr.py fails on lldb arm/aarch64 linux
buildbot but not reproducible on test machine. Skipping for now.
2021-06-03 14:57:00 +05:00
Muhammad Omair Javaid f7e591161d [LLDB] Skip TestDataFormatterStdUniquePtr.py on arm/linux
TestDataFormatterStdUniquePtr.py fails on lldb arm/aarch64 linux
buildbot but not reproducible on test machine. Skipping for now.
2021-06-03 14:54:03 +05:00
Walter Erquinigo e65242e37a [NFC][trace][intel-pt] small test fixes
These tests started failing after a change in the disassembler. The fix
is pretty simple though.
2021-06-02 14:06:25 -07:00
Raphael Isemann 0ec761c3fc [lldb] Preserve type sugar when using SBValue::Dereference on C++ references
When checking for type properties we usually want to strip all kind of type
sugar from the type. For example, sugar like Clang's ElaboratedType or typedefs
rarely influence the fundamental behaviour of a type such as its byte size.

However we always need to preserve type sugar for everything else as it does
matter for users that their variable of type `size_t` instead of `unsigned long`
for example.

This patch fixes one such bug when trying to use the SBValue API to dereference
a type.

Reviewed By: werat, shafik

Differential Revision: https://reviews.llvm.org/D103532
2021-06-02 19:23:11 +02:00
Bruce Mitchener 251a5d9d52 [lldb/API] Expose triple for SBProcessInfo.
This is present when doing a `platform process list` and is
tracked by the underlying code. To do something like the
process list via the SB API in the future, this must be
exposed.

Differential Revision: https://reviews.llvm.org/D103375
2021-06-02 11:35:11 +07:00
Jim Ingham 658f6ed152 Make ignore counts work as "after stop" modifiers so they play nicely with conditions
Previously ignore counts were checked when we stopped to do the sync callback in Breakpoint::ShouldStop. That meant we would do all the ignore count work even when
there is also a condition says the breakpoint should not stop.

That's wrong, lldb treats breakpoint hits that fail the thread or condition checks as "not having hit the breakpoint". So the ignore count check should happen after
the condition and thread checks in StopInfoBreakpoint::PerformAction.

The one side-effect of doing this is that if you have a breakpoint with a synchronous callback, it will run the synchronous callback before checking the ignore count.
That is probably a good thing, since this was already true of the condition and thread checks, so this removes an odd asymmetry. And breakpoints with sync callbacks
are all internal lldb breakpoints and there's not a really good reason why you would want one of these to use an ignore count (but not a condition or thread check...)

Differential Revision https://reviews.llvm.org/D103217
2021-06-01 18:22:27 -07:00
Bruce Mitchener 36597e4719 [lldb] Fix typos. NFC.
Differential Revision: https://reviews.llvm.org/D103381
2021-05-31 06:48:57 +07:00
Walter Erquinigo 0283abee5c [lldb] Fix gnu_libstdcpp's update methods
The variable.rst documentation says:

```
If it returns a value, and that value is True, LLDB will be allowed to cache the children and the children count it previously obtained, and will not return to the provider class to ask.  If nothing, None, or anything other than True is returned, LLDB will discard the cached information and ask. Regardless, whenever necessary LLDB will call update.
```

However, several update methods in gnu_libstdcpp.py were returning True,
which made lldb unaware of any changes in the corresponding objects.
This problem was visible by lldb-vscode in the following way:

- If a breakpoint is hit and there's a vector with the contents {1, 2},
  it'll be displayed correctly.
- Then the user steps and the next stop contains the vector modified.
  The program changed it to {1, 2, 3}
- frame var then displays {1, 2} incorrectly, due to the caching caused
by the update method

It's worth mentioning that none of libcxx.py'd update methods return True. Same for LibCxxVector.cpp, which returns false.

Added a very simple test that fails without this fix.

Differential Revision: https://reviews.llvm.org/D103209
2021-05-26 14:52:38 -07:00
Raphael Isemann a3a95286a7 [lldb] X-FAIL TestCPPStaticMembers on Windows
This was originally failed because of llvm.org/pr21765 which describes that
LLDB can't call a debugee's functions, but I removed the (unnecessary)
function call in the rewrite. It seems that the actual bug here is that we
can't lookup static members at all, so let's X-FAIL the test for the right
reason.
2021-05-25 13:10:19 +02:00
Raphael Isemann 3bf96b0329 [lldb] Disable minimal import mode for RecordDecls that back FieldDecls
Clang adds a Decl in two phases to a DeclContext. First it adds it invisible and
then it makes it visible (which will add it to the lookup data structures). It's
important that we can't do lookups into the DeclContext we are currently adding
the Decl to during this process as once the Decl has been added, any lookup will
automatically build a new lookup map and add the added Decl to it. The second
step would then add the Decl a second time to the lookup which will lead to
weird errors later one. I made adding a Decl twice to a lookup an assertion
error in D84827.

In the first step Clang also does some computations on the added Decl if it's
for example a FieldDecl that is added to a RecordDecl.

One of these computations is checking if the FieldDecl is of a record type
and the record type has a deleted constexpr destructor which will delete
the constexpr destructor of the record that got the FieldDecl.

This can lead to a bug with the way we implement MinimalImport in LLDB
and the following code:

```
struct Outer {
  typedef int HookToOuter;
  struct NestedClass {
    HookToOuter RefToOuter;
  } NestedClassMember; // We are adding this.
};
```

1. We just imported `Outer` minimally so far.
2. We are now asked to add `NestedClassMember` as a FieldDecl.
3. We import `NestedClass` minimally.
4. We add `NestedClassMember` and clang does a lookup for a constexpr dtor in
   `NestedClass`. `NestedClassMember` hasn't been added to the lookup.
5. The lookup into `NestedClass` will now load the members of `NestedClass`.
6. We try to import the type of `RefToOuter` which will try to import the `HookToOuter` typedef.
7. We import the typedef and while importing we check for conflicts in `Outer` via a lookup.
8. The lookup into `Outer` will cause the invisible `NestedClassMember` to be added to the lookup.
9. We continue normally until we get back to the `addDecl` call in step 2.
10. We now add `NestedClassMember` to the lookup even though we already did that in step 8.

The fix here is disabling the minimal import for RecordTypes from FieldDecls. We
actually already did this, but so far we only force the definition of the type
to be imported *after* we imported the FieldDecl. This just moves that code
*before* we import the FieldDecl so prevent the issue above.

Reviewed By: shafik, aprantl

Differential Revision: https://reviews.llvm.org/D102993
2021-05-25 12:08:50 +02:00
Raphael Isemann 8b656b8846 [lldb] Re-eanble and rewrite TestCPPStaticMembers
It's not clear why the whole test got disabled, but the linked bug report
has since been fixed and the only part of it that still fails is the test
for the too permissive lookup. This re-enables the test, rewrites it to use
the modern test functions we have and splits the failing part into its
own test that we can skip without disabling the rest.
2021-05-25 11:52:28 +02:00
Raphael Isemann 5d7c1d8f33 [lldb] Readd deleted variable in the sample test
In D102771 wanted to make `test_var` global to demonstrate the a no-launch test,
but the old variable is still needed for another test. This just creates the
global var with a different name to demonstrate the no-launch functionality.
2021-05-24 16:29:25 +02:00
Raphael Isemann 54c2687292 [lldb] Introduce createTestTarget for creating a valid target in API tests
At the moment nearly every test calls something similar to
`self.dbg.CreateTarget(self.getBuildArtifact("a.out"))` and them sometimes
checks if the created target is actually valid with something like
`self.assertTrue(target.IsValid(), "some useless text")`.

Beside being really verbose the error messages generated by this pattern are
always just indicating that the target failed to be created but now why.

This patch introduces a helper function `createTestTarget` to our Test class
that creates the target with the much more verbose `CreateTarget` overload that
gives us back an SBError (with a fancy error). If the target couldn't be created
the function prints out the SBError that LLDB returned and asserts for us. It
also defaults to the "a.out" build artifact path that nearly all tests are using
to avoid to hardcode "a.out" in every test.

I converted a bunch of tests to the new function but I'll do the rest of the
test suite as follow ups.

Reviewed By: JDevlieghere

Differential Revision: https://reviews.llvm.org/D102771
2021-05-24 16:18:44 +02:00
Daniel Rodríguez Troitiño 5e327785da [lldb] Match test dependencies name to other LLVM projects.
Other LLVM projects use the suffix `-depends` for the test dependencies,
however LLDB uses `-deps` and seems to be the only project under the
LLVM to do so.

In order to make the projects more homogeneous, switch all the
references to `lldb-test-deps` to `lldb-test-depends`.

Additionally, provide a compatibility target with the old name and
depending on the new name, in order to not break anyone workflow.

Reviewed By: JDevlieghere

Differential Revision: https://reviews.llvm.org/D102889
2021-05-21 00:10:27 -07:00
Andy Yankovsky 6c83d4a60b [lldb] Enable TestCppBitfields on Windows
The test works correctly on Windows, the linked bug has been resolved.

Reviewed By: teemperor

Differential Revision: https://reviews.llvm.org/D102769
2021-05-19 17:04:19 +02:00
Andy Yankovsky 0bab7b26f4 [lldb] Encode `bool` as unsigned int
`bool` is considered to be unsigned according to `std::is_unsigned<bool>::value` (and `Type::GetTypeInfo`). Encoding it as signed int works fine for normal variables and fields, but breaks when reading the values of boolean bitfields. If the field is declared as `bool b : 1` and has a value of `0b1`, the call to `SBValue::GetValueAsSigned()` will return `-1`.

Reviewed By: teemperor

Differential Revision: https://reviews.llvm.org/D102685
2021-05-19 15:32:17 +02:00
Raphael Isemann ff95486513 [lldb][NFC] Remove sample test boilerplate from TestBreakOnCPP11Initializers 2021-05-19 15:22:11 +02:00
Med Ismail Bennani 1b4d5b3bf3 [lldb/API] Use a valid LineEntry object in SBCompileUnit::FindLineEntryIndex
This patch updates `SBCompileUnit::FindLineEntryIndex` to pass a valid
`LineEntry` pointer to `CompileUnit::FindLineEntry`.

This caused `LineTable::FindLineEntryIndexByFileIndexImpl` to return its
`best_match` initial value (UINT32_MAX).

rdar://78115426

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

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2021-05-18 01:28:53 +01:00
Jim Ingham 82a3883715 Revert "Reset the wakeup timeout when we re-enter the continue wait."
This reverts commit bd5751f3d2.
This patch series is causing us to every so often miss switching
the state from eStateRunning to eStateStopped when we get the stop
packet from the debug server.

Reverting till I can figure out how that could be happening.
2021-05-17 15:37:26 -07:00
Jim Ingham 10c309ad81 Removing test...
Actually, I don't think this test is going to be stable enough
to be worthwhile.  Let me see if I can think of a better way to
test this.
2021-05-11 18:27:37 -07:00
Jim Ingham 0f2eb7e6e5 This test is failing on Linux, skip while I investigate.
The gdb-remote tests are a bit artificial, depending on
Python threading, and sleeps.  So I'm not 100% surprised it doesn't
work straight up on another XSsystem.
2021-05-11 18:13:56 -07:00
Jim Ingham 9558b602b2 Add an "interrupt timeout" to Process, and pipe that through the
ProcessGDBRemote plugin layers.

Also fix a bug where if we tried to interrupt, but the ReadPacket
wakeup timer woke us up just after the timeout, we would break out
the switch, but then since we immediately check if the response is
empty & fail if it is, we could end up actually only giving a
small interval to the interrupt.

Differential Revision: https://reviews.llvm.org/D102085
2021-05-11 11:57:08 -07:00
Jim Ingham 72ba78c29e When SendContinuePacketAndWaitForResponse returns eStateInvalid, don't fetch more packets.
This looks like just an oversight in the AsyncThread function.  It gets a result of
eStateInvalid, and then marks the process as exited, but doesn't set "done" to true,
so we go to fetch another event.  That is not safe, since you don't know when that
extra packet is going to arrive.  If it arrives while you are tearing down the
process, the internal-state-thread might try to handle it when the process in not
in a good state.

Rather than put more effort into checking all the shutdown paths to make sure this
extra packet doesn't cause problems, just don't fetch it.  We weren't going to do
anything useful with it anyway.

The main part of the patch is setting "done = true" when we get the eStateInvalid.
I also added a check at the beginning of the while(done) loop to prevent another error
from getting us to fetch packets for an exited process.

I added a test case to ensure that if an Interrupt fails, we call the process
exited.  I can't test exactly the error I'm fixing, there's no good way to know
that the stop reply for the failed interrupt wasn't fetched.  But at least this
asserts that the overall behavior is correct.

Differential Revision: https://reviews.llvm.org/D101933
2021-05-06 14:11:42 -07:00
Raphael Isemann 3026f75ed0 [lldb][NFC] Make assert in TestStaticVariables more expressive 2021-05-06 16:00:24 +02:00
Med Ismail Bennani 9775582e34 [lldb/Test] Disable testBreakpointByLineAndColumnNearestCode on Windows
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2021-05-05 06:04:08 +00:00
Med Ismail Bennani 35ecfda01c [lldb/Symbol] Fix column breakpoint `move_to_nearest_code` match
This patch fixes the column symbol resolution when creating a breakpoint
with the `move_to_nearest_code` flag set.

In order to achieve this, the patch adds column information handling in
the `LineTable`'s `LineEntry` finder. After experimenting a little, it
turns out the most natural approach in case of an inaccurate column match,
is to move backward and match the previous `LineEntry` rather than going
forward like we do with simple line breakpoints.

The patch also reflows the function to reduce code duplication.

Finally, it updates the `BreakpointResolver` heuristic to align it with
the `LineTable` method.

rdar://73218201

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

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2021-05-05 05:07:50 +00:00
Walter Erquinigo ade59d5309 [trace] Dedup different source lines when dumping instructions + refactor
When dumping the traced instructions in a for loop, like this one

  4:  for (int a = 0; a < n; a++)
  5:    do something;

there might be multiple LineEntry objects for line 4, but with different address ranges. This was causing the dump command to dump something like this:

```
  a.out`main + 11 at main.cpp:4
    [1] 0x0000000000400518    movl   $0x0, -0x8(%rbp)
    [2] 0x000000000040051f    jmp    0x400529                  ; <+28> at main.cpp:4
  a.out`main + 28 at main.cpp:4
    [3] 0x0000000000400529    cmpl   $0x3, -0x8(%rbp)
    [4] 0x000000000040052d    jle    0x400521                  ; <+20> at main.cpp:5
```

which is confusing, as main.cpp:4 appears twice consecutively.

This diff fixes that issue by making the line entry comparison strictly about the line, column and file name. Before it was also comparing the address ranges, which we don't need because our output is strictly about what the user sees in the source.

Besides, I've noticed that the logic that traverses instructions and calculates symbols and disassemblies had too much coupling, and made my changes harder to implement, so I decided to decouple it. Now there are two methods for iterating over the instruction of a trace. The existing one does it on raw load addresses, but the one provides a SymbolContext and an InstructionSP, and does the calculations efficiently (not as efficient as possible for now though), so the caller doesn't need to care about these details. I think I'll be using that iterator to reconstruct the call stacks.

I was able to fix a test with this change.

Differential Revision: https://reviews.llvm.org/D100740
2021-05-04 19:40:52 -07:00
Muhammad Omair Javaid 69a3269250 Support AArch64 PAC elf-core register read
This adds support for reading AArch64 Pointer Authentication regset
from elf-core file. Also includes a test-case for the same. Furthermore
there is also a slight refactoring of RegisterContextPOSIXCore_arm64
members and constructor. linux-aarch64-pac.core file is generated using
lldb/test/API/functionalities/postmortem/elf-core/main.c with following
clang arguments:
-march=armv8.5-a -mbranch-protection=pac-ret+leaf -nostdlib -static -g

Reviewed By: DavidSpickett

Differential Revision: https://reviews.llvm.org/D99941
2021-05-03 16:04:47 +05:00
David Spickett f31e390453 [lldb][AArch64] Don't check for VmFlags in smaps files
AArch64 kernel builds default to having /smaps and
the "VmFlags" line was added in 3.8. Long before MTE
was supported.

So we can assume that if you're AArch64 with MTE,
you can run this test.

The previous method of checking had a race condition
where the process we read smaps for, could finish before
we get to read the file.

I explored some alternatives but in the end I think
it's fine to just assume we have what we need.

Reviewed By: omjavaid

Differential Revision: https://reviews.llvm.org/D100493
2021-04-29 09:30:14 +01:00
Adrian Prantl 711a473cd9 Update testcase for D101333. 2021-04-27 13:24:24 -07:00
Adrian Prantl 25bf137b1e Also display the underlying error message when displaying a fixit
When the user running LLDB with default settings sees the fixit
notification it means that the auto-applied fixit didn't work. This
patch shows the underlying error message instead of just the fixit to
make it easier to understand what the error in the expression was.

Differential Revision: https://reviews.llvm.org/D101333
2021-04-27 10:40:42 -07:00
Michał Górny ca7824c2a8 [lldb] [gdb-remote] Report QPassSignals and qXfer via extensions API
Remove hardcoded platform list for QPassSignals, qXfer:auxv:read
and qXfer:libraries-svr4:read and instead query the process plugin
via the GetSupportedExtensions() API.

Differential Revision: https://reviews.llvm.org/D101241
2021-04-27 19:34:00 +02:00
Raphael Isemann a0c735e29a [lldb] Skip TestPointerToMemberTypeDependingOnParentSize on Windows and GCC
The test added in D100977 is failing to compile on these platforms. This seems
to be caused by GCC, MSVC and Clang@Windows rejecting the code because
`ToLayout` isn't complete when pointer_to_member_member is declared (even though
that seems to be valid code).

This also reverts the test changes in the lazy-loading test from D100977 as
that failed for the same reason.
2021-04-26 18:55:54 +02:00
Jonas Devlieghere 7d850db6b6 [lldb] Don't use ::fork or ::vfork on watchOS or tvOS
Update lldb-server to not use fork or vfork on watchOS and tvOS as these
functions are explicitly marked unavailable there.

llvm-project/lldb/test/API/tools/lldb-server/main.cpp:304:11:
error: 'fork' is unavailable: not available on watchOS
      if (fork() == 0)
          ^
WatchSimulator6.2.sdk/usr/include/unistd.h:447:8: note: 'fork' has been
explicitly marked unavailable here
pid_t    fork(void) __WATCHOS_PROHIBITED __TVOS_PROHIBITED;
         ^
llvm-project/lldb/test/API/tools/lldb-server/main.cpp:307:11:
error: 'vfork' is unavailable: not available on watchOS
      if (vfork() == 0)
          ^
WatchSimulator6.2.sdk/usr/include/unistd.h:602:8: note: 'vfork' has been
explicitly marked unavailable here
pid_t    vfork(void) __WATCHOS_PROHIBITED __TVOS_PROHIBITED;
         ^
2021-04-26 09:31:35 -07:00
Emre Kultursay e439a463a3 [lldb] Use forward type in pointer-to-member
This change is similar in spirit to the change at:
https://reviews.llvm.org/rG34c697c85e9d0af11a72ac4df5578aac94a627b3

It fixes the problem where the layout of a type was being accessed
while its base classes were not populated yet; which caused an
incorrect layout to be produced and cached.

This fixes PR50054

Reviewed By: teemperor

Differential Revision: https://reviews.llvm.org/D100977
2021-04-26 15:23:58 +02:00
Michał Górny bbae0c1f7b [lldb] [llgs] Support owning and detaching extra processes
Add a NativeDelegate API to pass new processes (forks) to LLGS,
and support detaching them via the 'D' packet.  A 'D' packet without
a specific PID detaches all processes, otherwise it detaches either
the specified subprocess or the main process, depending on the passed
PID.

Differential Revision: https://reviews.llvm.org/D100191
2021-04-24 11:08:33 +02:00
Michał Górny 312257688e [lldb] [Process] Introduce protocol extension support API
Introduce a NativeProcessProtocol API for indicating support for
protocol extensions and enabling them.  LLGS calls
GetSupportedExtensions() method on the process factory to determine
which extensions are supported by the plugin.  If the future is both
supported by the plugin and reported as supported by the client, LLGS
enables it and reports to the client as supported by the server.

The extension is enabled on the process instance by calling
SetEnabledExtensions() method.  This is done after qSupported exchange
(if the debugger is attached to any process), as well as after launching
or attaching to a new inferior.

The patch adds 'fork' extension corresponding to 'fork-events+'
qSupported feature and 'vfork' extension for 'vfork-events+'.  Both
features rely on 'multiprocess+' being supported as well.

Differential Revision: https://reviews.llvm.org/D100153
2021-04-24 11:08:33 +02:00
Adrian Prantl 007158ac42 Skip unreliable LLDB tests when running under asan 2021-04-22 11:55:43 -07:00
Raphael Isemann d616a6bd10 [lldb] Fix that the expression commands --top-level flag overwrites --allow-jit false
The `--allow-jit` flag allows the user to force the IR interpreter to run the
provided expression.

The `--top-level` flag parses and injects the code as if its in the top level
scope of a source file.

Both flags just change the ExecutionPolicy of the expression:
* `--allow-jit true` -> doesn't change anything (its the default)
* `--allow-jit false` -> ExecutionPolicyNever
* `--top-level` -> ExecutionPolicyTopLevel

Passing `--allow-jit false` and `--top-level` currently causes the `--top-level`
to silently overwrite the ExecutionPolicy value that was set by `--allow-jit
false`. There isn't any ExecutionPolicy value that says "top-level but only
interpret", so I would say we reject this combination of flags until someone
finds time to refactor top-level feature out of the ExecutionPolicy enum.

The SBExpressionOptions suffer from a similar symptom as `SetTopLevel` and
`SetAllowJIT` just silently disable each other. But those functions don't have
any error handling, so not a lot we can do about this in the meantime.

Reviewed By: labath, kastiglione

Differential Revision: https://reviews.llvm.org/D91780
2021-04-22 18:51:03 +02:00
Raphael Isemann d2223c7a49 [lldb] XFAIL TestStoppedInStaticMemberFunction on Windows
It seems we can't find the symbols of static members on Windows? The bug is not
 relevant to what this test is actually testing so let's just XFAIL it.
2021-04-22 13:46:27 +02:00
Raphael Isemann 00764c36ed [lldb] Add support for evaluating expressions in static member functions
At the moment the expression parser doesn't support evaluating expressions in
static member functions and just pretends the expression is evaluated within a
non-member function. This causes that all static members are inaccessible when
doing unqualified name lookup.

This patch adds support for evaluating in static member functions. It
essentially just does the same setup as what LLDB is already doing for
non-static member functions (i.e., wrapping the expression in a fake member
function) with the difference that we now mark the wrapping function as static
(to prevent access to non-static members).

Reviewed By: shafik, jarin

Differential Revision: https://reviews.llvm.org/D81550
2021-04-22 12:14:31 +02:00
Jonas Devlieghere 39ea3ceda3 [lldb] Disable TestSimulatorPlatform.py because it's causing a SIGHUP
Ever since Dave Zarzycki's patch to sort test start times based on prior
test timing data (https://reviews.llvm.org/D98179) the test suite aborts
with a SIGHUP. I don't believe his patch is to blame, but rather
uncovers an preexisting issue by making test runs more deterministic.

I was able to narrow down the issue to TestSimulatorPlatform.py. The
issue also manifests itself on the standalone bot on GreenDragon [1].
This patch disables the test until we can figure this out.

[1] http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-standalone/

rdar://76995109
2021-04-21 20:00:51 -07:00
Walter Erquinigo c9a0754b44 [lldb-vscode] Distinguish shadowed variables in the scopes request
VSCode doesn't render multiple variables with the same name in the variables view. It only renders one of them. This is a situation that happens often when there are shadowed variables.
The nodejs debugger solves this by adding a number suffix to the variable, e.g. "x", "x2", "x3" are the different x variables in nested blocks.

In this patch I'm doing something similar, but the suffix is " @ <file_name:line>), e.g. "x @ main.cpp:17", "x @ main.cpp:21". The fallback would be an address if the source and line information is not present, which should be rare.

This fix is only needed for globals and locals. Children of variables don't suffer of this problem.

When there are shadowed variables
{F16182150}

Without shadowed variables
{F16182152}

Modifying these variables through the UI works

Reviewed By: clayborg

Differential Revision: https://reviews.llvm.org/D99989
2021-04-21 15:09:39 -07:00
Walter Erquinigo 64f47c1e58 [lldb-vscode] redirect stderr/stdout to the IDE's console
In certain occasions times, like when LLDB is initializing and
evaluating the .lldbinit files, it tries to print to stderr and stdout
directly. This confuses the IDE with malformed data, as it talks to
lldb-vscode using stdin and stdout following the JSON RPC protocol. This
ends up terminating the debug session with the user unaware of what's
going on. There might be other situations in which this can happen, and
they will be harder to debug than the .lldbinit case.

After several discussions with @clayborg, @yinghuitan and @aadsm, we
realized that the best course of action is to simply redirect stdout and
stderr to the console, without modifying LLDB itself. This will prove to
be resilient to future bugs or features.

I made the simplest possible redirection logic I could come up with. It
only works for POSIX, and to make it work with Windows should be merely
changing pipe and dup2 for the windows equivalents like _pipe and _dup2.
Sadly I don't have a Windows machine, so I'll do it later once my office
reopens, or maybe someone else can do it.

I'm intentionally not adding a stop-redirecting logic, as I don't see it
useful for the lldb-vscode case (why would we want to do that, really?).

I added a test.

Note: this is a simpler version of D80659. I first tried to implement a
RIIA version of it, but it was problematic to manage the state of the
thread and reverting the redirection came with some non trivial
complexities, like what to do with unflushed data after the debug
session has finished on the IDE's side.
2021-04-21 14:48:48 -07:00
Walter Erquinigo 12a2507646 Fix TestVSCode_launch test
Broken in https://lab.llvm.org/buildbot/#/builders/96/builds/6933

We don't really need to run this test on arm, but would be worth fixing
it later.
2021-04-21 14:33:34 -07:00
Walter Erquinigo 79fbbeb412 [lldb-vscode] Add postRunCommands
This diff ass postRunCommands, which are the counterpart of the preRunCommands. TThey will be executed right after the target is launched or attached correctly, which means that the targets can assume that the target is running.

Differential Revision: https://reviews.llvm.org/D100340
2021-04-21 13:51:30 -07:00
Jonas Devlieghere 5d1c43f333 [lldb] Use the compiler from the SDK in simulator tests
Use the clang compiler from the SDK to build the simulator test programs
to ensure we pick up the correct libc++.
2021-04-21 13:22:58 -07:00
Pavel Labath 55ee541653 [lldb/test] Clean up TestThreadSpecificBpPlusCondition inferior
The test had a race that could cause two threads to end up with the same
"thread local" value. I believe this would not cause the test to fail,
but it could cause it to succeed even when the functionality is broken.

The new implementation removes this uncertainty, and removes a lot of
cruft left over from the time this test was written using pthreads.
2021-04-21 17:37:30 +02:00
Pavel Labath 953f580b90 [lldb/test] Modernize lldb-server test inferior
Avoid c string manipulation by introducing a StringRef-like
consume_front operation.
2021-04-21 17:02:41 +02:00
Jonas Devlieghere cc68799056 [lldb] Stop unsetting LLDB_DEBUGSERVER_PATH from TestLaunchProcessPosixSpawn
We no longer need this after Pavel's change to automatically find debug
servers to test. (3ca7b2d)
2021-04-19 12:28:22 -07:00