Synthetic providers for collection types use a child name format of
"[N]".
This `ValueObjectSynthetic` to automatically convert child names in this
convention to the index embedded in the subscript string. With this
change, synthetic formatters for collections will only need to implement
`GetIndexOfChildWithName` or `get_child_index` for non-indexed
collection children. Some examples of non-indexed children are
`$$dereference$$` support, or "hidden" children.
The automatic conversion applies to N values that are less than the
number of children reported by the synthetic provider.
This reverts commit 97572c1860efeeb97b5940927cee72081b61810a.
This patch seems to cause TestWatchpointCommandPython.py to time out
on the ubuntu buildbots (but nowhere else that I can find so far.) The
timeout is weird too, the TEST FILE is timing out but the individual
tests aren't being shown and there's no other output. Grrr...
Anyway I'll revert this and then see if I can do some guessing about
how this change might cause the test to fail.
This reverts commit 894408ded44151e4e34a3402210f671355d66310.
These tests were added by 97572c1860efeeb97b5940927cee72081b61810a
and I am reverting that as well.
When lldb stops to run a breakpoint condition or other callback that has
to happen between the private stop and returning control to the user, it
will run in the state where the public state is still "running". But if
the callback needs to run lldb commands or python code, it needs to see
the correct "stop" state.
We used to handle that by switching the public state to stopped before
running the callbacks. However, that opened a window where we are still
handling the stop event and another thread would be allowed to continue
the target or do other actions that can interfere with that orderly
process.
This patch adds the ability to designate a particular thread as "seeing
the private state" while all other threads see the "public state". Then
when we run a breakpoint callback, no threads but the one that is
actually running the callback will see the state change until the event
has been delivered to the primary state listener.
It also adds a test that while a long-running breakpoint callback runs,
another thread continues to see the state as running.
I was working on something and broke the handling of breakpoint
conditions that crash. In fixing that I noticed that there wasn't a test
for this scenario, so this PR adds one.
---------
Co-authored-by: Med Ismail Bennani <ismail@bennani.ma>
Symbols added by linker scripts do not have debug information or types,
but they do have addresses. Sometimes users need to see the addresses of
these symbols. Currently these symbols end up being assigned
'eSymbolTypeInvalid', so any attempt to look at them fails. This fixes
that issue.
Adding the `operator==` and `operator!=` for SBBlock. This should allow
us to compare blocks within a frame, like:
```python
block = frame.GetBlock()
while True:
if block == frame.GetFrameBlock():
# we're at the top function scope.
else:
# we're at an inner block scope.
```
This reverts commit 49c3cd15e8b4c21dd86eefdc76754ddfc2a7a65e.
I was going back and forth between llvm.org and my fork to prepare
this PR, but mistakenly pushed it from the wrong checkout.
Let's revert this and do it right...
Currently, `DynamicLoaderPOSIXDYLD::GetThreadLocalData()` only supports
the TLS memory layout where the thread pointer register points to the
start of the `pthread` structure, and the address of the DTV pointer can
be calculated by adding the offset of the `dtv` field to `tp`. On ARM
(and AArch64), the thread pointer points directly to `dtv`. The patch
improves the detection of the actual memory layout in the method and
adjusts the calculations for the new case, thus adding support for
thread-local variables on ARM Linux.
When multiple threads are stopped at the same breakpoint, LLDB currently
steps each thread over the breakpoint one at a time. Each step requires
disabling the breakpoint, single-stepping one thread, and re-enabling
it, resulting in N disable/enable cycles and N individual vCont packets
for N threads. This is a common scenario for hot breakpoints in
multithreaded programs and scales poorly.
This patch batches the step-over so that all threads at the same
breakpoint site are stepped together in a single vCont packet, with the
breakpoint disabled once at the start and re-enabled once after the last
thread finishes.
At the top of WillResume, any leftover StepOverBreakpoint plans from a
previous cycle are popped with their re-enable side effect suppressed
via SetReenabledBreakpointSite, giving a clean slate.
SetupToStepOverBreakpointIfNeeded then creates fresh plans for all
threads that still need to step over a breakpoint, and these are grouped
by breakpoint address.
For groups with multiple threads, each plan is set to defer its
re-enable through SetDeferReenableBreakpointSite. Instead of re-enabling
the breakpoint directly when a plan completes, it calls
ThreadFinishedSteppingOverBreakpoint, which decrements a per-address
tracking count. The breakpoint is only re-enabled when the count reaches
zero.
All threads in the largest group are resumed together in a single
batched vCont packet. If some threads don't complete their step in one
cycle, the pop-and-recreate logic naturally re-batches the remaining
threads on the next WillResume call.
For 10 threads at the same breakpoint, this reduces the operation from
10 z0/Z0 pairs and 10 vCont packets to 1 z0 + 1 Z0 and a few
progressively smaller batched vCont packets.
EDIT:
Tried to merge this PR twice, the first time the test was flaky so we
had to revert. The second time, we broke 2 tests on windows machine:
https://lab.llvm.org/buildbot/#/builders/141/builds/15798
The tests that were failing were failing because the cleanup code in
`WillResume` was popping **ALL** `StepOverBreakpoint` plans, including
non-deferred ones from incomplete single-steps.
The issue was:
1) Multiple threads hit the same breakpoint. One thread's breakpoint
condition evaluates to false, so it needs to auto-continue.
2) A `StepOverBreakpoint` plan is created for that thread
(non-deferred).
3) On the next WillResume, the cleanup pops that non-deferred plan.
4) Now the `StopOthers` scan finds no thread with a StopOthers() plan,
so thread_to_run stays null.
5) The else branch runs, calling `SetupToStepOverBreakpointIfNeeded` on
**ALL** threads, including the thread that legitimately hit the
breakpoint with a true condition.
6) That thread gets a new `StepOverBreakpoint` plan pushed, which
overwrites its breakpoint stop reason with trace when the step
completes.
The error `trace (2) != breakpoint (3)` confirms this, the thread that
should have reported breakpoint as its stop reason instead reports
trace, because an unwanted `StepOverBreakpoint` plan was pushed on it
and completed.
The newly added code fixes it by only popping plans that have
`GetDeferReenableBreakpointSite() == true`
Co-authored-by: Bar Soloveychik <barsolo@fb.com>
This patch fixes tests on systems where `wchar`'s underlying type is
`unsigned long`, or `long` and `int` types have the same width, so
`unsigned int` gets promoted to `unsigned long` during binary addition.
These tests check that `wchar` types get promoted to regular integer
types at all.
This avoids formatting empty space when a range of text formatted by
ANSI codes is split across lines.
This is not currently done in any option, but the `${...}` syntax we
have does support marking any range of text, so it could be done in
future, and fixing it is simple.
As an example, if I change a breakpoint option:
```
"${S}et the breakpoint only in this shared library. Can repeat "
- "this option multiple times to specify multiple shared libraries.">;
+ "this option multiple ${times to specify multiple} shared libraries.">;
```
This applies the underline to words that will be split across lines. In
the outputs below, `^` represents an underlined character.
With spaces:
```
-s <shlib-name> ( --shlib <shlib-name> )
Set the breakpoint only in this shared library. Can repeat this option multiple times to
^^^^^^^^
specify multiple shared libraries.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
The indent and the text are underlined, this is not what we want.
With cursor movement:
```
-s <shlib-name> ( --shlib <shlib-name> )
Set the breakpoint only in this shared library. Can repeat this option multiple times to
^^^^^^^^
specify multiple shared libraries.
^^^^^^^^^^^^^^^^
```
Only the text is underlined, which is correct.
If we are not allowed to use ANSI (use-color is off), then the
descriptions will be stripped of ANSI anyway, so this is not a problem.
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
This test exercises macOS-specific linker functionality (-delay_library)
and uses a hardcoded local working directory for the launch info. It
should not run against a remote platform where neither condition holds.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
Adjusting `VariableReferenceStorage` to only need to track permanent vs
temporary storage by making `VariableStore` the common base class.
Moved the subclasses of `VariableStore` into the Variables.cpp file,
since they're no long referenced externally.
Expanding on the tests by adding an updated core dump with variables in
the argument scope we can use to validate variable storage.
Update the test to more cleanly handle making a 'blocking' call using a
custom command instead of python `time.sleep`, which we cannot easily
interrupt.
This should improve the overall performance of the tests, locally they
took around 30s and now finish in around 6s.
Fixes#177570, and a bunch of FIXMEs for other tests known to be
incorrect.
To do this, I have adapted code from the existing ansi::TrimAndPad. At
first I tried a wrapper function, but there's a few things we need to
handle that cannot be done with a simple wrapper.
We must only split at word boundaries. This requires knowing whether the
last adjustment, which may be the final adjustment, was made at, or just
before, a word boundary. Also it must check for single words wider than
the requested width (though this you could do with a wrapper).
For this reason, the new TrimAtWordBoundary has more special case checks
and a more complex inner loop. Though the core is the same split into
left, ansi escape code and right that TrimAndPad uses.
It is that splitting that implements the "bias" we need to print
correctly formatted characters. When you have a preceeding ANSI code,
this must be included in the printed range, same for proceeding.
TrimAndPad already handled this, and I've copied that logic over.
TrimAndPad also used Unicode aware functions, which fixes the known
issues with Unicode (though no command option actually uses Unicode at
the moment).
This PR replaces PR #181860, where I tried to implement all this using a
strategy that used "visible indexes" to decide where to cut the lines,
and then converted those into "actual indexes" to know what to print.
This worked for most cases, but adding the "bias" was very complex. The
preceeding codes were quite easy to do, but proceeding proved to be too
complex.
I also had the feeling I was revinventing TrimAndPad and though it
didn't turn out to be that simple, it wasn't far off.
As the majority of the work is now done in TrimAtWordBoundary, I have
reused some existing OutputWordWrappedLines tests for the new function.
Some tests were using `self.filecheck` with `platform shell cat {log}`
to validate test behavior through log inspection.
This doesn't work when running the testsuite against a remote platform
since the logs are saved on the host's filesystem.
This patch refactors those call sites to use the new `filecheck_log`
helper, which ensures the log file is always read from the host
platform.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
Some tests are using logs to validate that a test behaves correctly
however they used `platform shell cat {log}` to read the logfile.
This doesn't work when running the testsuite against a remote platform
since the logs are saved on the host's filesystem.
This patch addresses those failures by making sure we read the log file
from the host platform.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
Re-land https://github.com/llvm/llvm-project/pull/180101 since it was
reverted here https://github.com/llvm/llvm-project/pull/182431 because
of a flaky test. This PR include the modified test that should pass from
https://github.com/llvm/llvm-project/pull/182415 :
When multiple threads are stopped at the same breakpoint, LLDB currently
steps each thread over the breakpoint one at a time. Each step requires
disabling the breakpoint, single-stepping one thread, and re-enabling
it, resulting in N disable/enable cycles and N individual vCont packets
for N threads. This is a common scenario for hot breakpoints in
multithreaded programs and scales poorly.
This patch batches the step-over so that all threads at the same
breakpoint site are stepped together in a single vCont packet, with the
breakpoint disabled once at the start and re-enabled once after the last
thread finishes.
At the top of WillResume, any leftover StepOverBreakpoint plans from a
previous cycle are popped with their re-enable side effect suppressed
via SetReenabledBreakpointSite, giving a clean slate.
SetupToStepOverBreakpointIfNeeded then creates fresh plans for all
threads that still need to step over a breakpoint, and these are grouped
by breakpoint address.
For groups with multiple threads, each plan is set to defer its
re-enable through SetDeferReenableBreakpointSite. Instead of re-enabling
the breakpoint directly when a plan completes, it calls
ThreadFinishedSteppingOverBreakpoint, which decrements a per-address
tracking count. The breakpoint is only re-enabled when the count reaches
zero.
All threads in the largest group are resumed together in a single
batched vCont packet. If some threads don't complete their step in one
cycle, the pop-and-recreate logic naturally re-batches the remaining
threads on the next WillResume call.
For 10 threads at the same breakpoint, this reduces the operation from
10 z0/Z0 pairs and 10 vCont packets to 1 z0 + 1 Z0 and a few
progressively smaller batched vCont packets.
Co-authored-by: Bar Soloveychik <barsolo@fb.com>
These tests sporadically fail on Green Dragon. My hypothesis is that one
test is rebuilding while another is trying to load a dSYM leading to a
mismatch.
The method claims to check if a is a subset of b, but the implementation
`a | b ==a` actually checks if b is a subset of a. This patch updated
the docstring.
This test occasionally fails on GreenDragon. When the directory already
exists and we enter the exception block, the `os.errno` symbol is not
found because it was deprecated in Python 3.7.
Instead, replace `os.mkdir` with `os.makedirs` because it can handle a
directory already existing.
This patch fixes cross platform Makefile.rules macros and adds the
`ECHO_TO_EXISTING_FILE` macros.
Using `echo` in a macro to write to a file had quoting issues.
There are two different ways to debug FreeBSD's kernel: core and remote
debugging. Remote debugging is done through `gdb-remote` plugin while
kernel dump and live core debugging is done through `freebsd-kernel`.
The name `freebsd-kernel` is vague for this reason, and following
`elf-core` and `mach-core`'s example, it would be clearer if this plugin
is renamed to `freebsd-kernel-core`.
---------
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
This implements reading the TPIDRURO register, which serves as the
thread pointer register on ARM Linux. Note that the register is not
displayed for core files because it is not included in the dump.
After https://github.com/llvm/llvm-project/pull/182297, we started generated `-gsimple-template-names` debug-info by default on macOS. The test was expecting template parameters in the error message. But with `simple-template-names` typenames would not contain template parameters (unless LLDB reconstructs them to do so). This formatter test was expecting template parameters, which would fail on macOS > 26.
Because the test is just concerned with checking that the `std::valarray` formatter works as expected (not that LLDB can retrieve typenames with/without template names), this patch relaxes the assertion.
In a follow-up we should fix up any type-name printing that would break with `simple-template-names`.
