The function that was supposed to iterate over all the breakpoints sharing
BKPT_NAME stopped after the first one because of a reversed "if success"
condition.
Differential Revision: https://reviews.llvm.org/D126730
lldb will only backtrace a fixed number of stack frames, as a
last-ditch attempt to avoid a runaway looping backtrace. It's
unusual that anyone ends up depending on this final safety net in
years. I picked the original number of 300000 was picked by seeing
how many stack frames I could make in a small recursive function
on Darwin systems before using the default stack space. Checking
again today on a modern system, I can exceed this limit & lldb will
not show the original invocation of the recursing call. Double the
old value to cover this larger maximum possible stack frame count,
as a default value.
(`target.process.thread.max-backtrace-depth`)
When cross compiling, a separate nested cmake is spawned, for building
host code generation tools such as lldb-tblgen.
When cross compiling on macOS, the nested native build would trigger
the lldb check for libc++, if testing is enabled (which it is by default).
(Even if `LLDB_INCLUDE_TESTS=OFF` is set on the main build, it has to
be passed separately in `CROSS_TOOLCHAIN_FLAGS_NATIVE` to reach the
nested build.)
Skip this check when building the host tools when cross compiling, as
the user won't try to run tests in that nested build.
(Alternatively, we could consider disabling all the `*_INCLUDE_TESTS`
by default in the nested host tools build.)
Differential Revision: https://reviews.llvm.org/D126557
so that they can be used to prime new Process runs. "process handle"
was also changed to populate the dummy target if there's no selected
target, so that the settings will get copied into new targets.
Differential Revision: https://reviews.llvm.org/D126259
After changing the "fallback" behavior when a user sets a breakpoint
without specifying a module the bad-address-breakpoint test case failed
incorrectly. This patch updates that test case in order to more
thoroughly discover an illegal address and use that as the means for
testing whether a breakpoint set at an illegal address fails to resolve.
Differential revision: https://reviews.llvm.org/D126109
A follow on to my patch for https://reviews.llvm.org/D126435
hit by an x86_64 linux bot; I assumed that a FileSpec had a
directory component and checked if the first character was a
'~'. This was not a valid assumption.
When reading source path remappings out of a dSYM, lldb currently
does tilde expansion -- expanding the tilde-username and checking
that the destination pathname exists, for each dSYM with the path
remappings. This cost happens during lldb's initial process launch
/ load, an especially perf-sensitive time. Inside Apple, we have
dSYMs with source path remappings pointing to NFS directories where
these extra stats for every dSYM can be very expensive if the network
is slow.
This patch instead keeps the source path mapping in the original
tilde-username terms and does the tilde expansion when we need
to read a specific source file from one of the modules. We'll
be stat'ing all of those inodes to load the source file anyway,
so the fact that we do the tilde expansion on every source file
we load, it doesn't cost us significantly.
Differential Revision: https://reviews.llvm.org/D126435
rdar://77091379
(cherry picked from commit c274b6e583)
When reading source path remappings out of a dSYM, lldb currently
does tilde expansion -- expanding the tilde-username and checking
that the destination pathname exists, for each dSYM with the path
remappings. This cost happens during lldb's initial process launch
/ load, an especially perf-sensitive time. Inside Apple, we have
dSYMs with source path remappings pointing to NFS directories where
these extra stats for every dSYM can be very expensive if the network
is slow.
This patch instead keeps the source path mapping in the original
tilde-username terms and does the tilde expansion when we need
to read a specific source file from one of the modules. We'll
be stat'ing all of those inodes to load the source file anyway,
so the fact that we do the tilde expansion on every source file
we load, it doesn't cost us significantly.
Differential Revision: https://reviews.llvm.org/D126435
rdar://77091379
I get to my work directory through a symlink, so the pathnames the
tests get for their build artifacts etc are via that symlink. There
are three tests which compare those symlink paths to a directory
received from dyld on macOS, which is the actual real pathname.
These tests have always failed for me on my dekstop but I finally
sat down to figure out why. Easy quick fix.
Skip all watchpoint hit-count/ignore-count tests for multithreaded
API tests for now on arm64 Darwin.
On AArch64, insns that trigger a WP are rolled back and we are
notified. lldb needs to disable the WP, insn step, re-enable it,
then report it to the user. lldb only does this full step action
for the "selected thread", and so when a program stops with
multiple threads hitting a stop reason, some of them watchpoints,
any non-selected-thread will not be completed in this way. But
all threads with the initial watchpoint exception will have their
hit-count/ignore-counts updated. When we resume execution, the
other threads sitting at the instruction will again execute &
trigger the WP exceptoin again, repeating until we've gone through
all of the threads.
This bug is being tracked in llvm.org/pr49433 and inside apple
in rdar://93863107
NativePDB often assumes that all debug info are available.
This is one step to make it more pervasive.
Differential Revision: https://reviews.llvm.org/D125844
On Ubuntu 18.04 with GCC 7.5 Intel trace code fails to build due to
failure to convert from
lldb_private::process_linux::IntelPTPerThreadProcessTraceUP to
Expected<lldb_private::process_linux::IntelPTPerThreadProcessTraceUP>.
This commit explicitely marks those unique_ptr values as being moved
which fixes the conversion error.
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D126402
This was inspired by D109336 which got reverted because we didn't want
the test to fail silently. This patch prints a more informative error
message when we fail to parse the simctl output while still failing the
test.
Differential revision: https://reviews.llvm.org/D126217
The LLDB website recommends using the CMake caches to build on macOS.
Although modules result in a faster build, this configuration tends to
break occasionally because it's specific to our platform. I don't expect
newcomers to be able to deal with those kind of breakages so don't
enable them by default.
Previous patch (https://reviews.llvm.org/D126013) added a new "optimized"
attribute to DAP stack frame this caused some tests, like
lldb-vscode/coreFile/TestVSCode_coreFile.py
to fail because the tests explicitly check for all attributes.
To fix the test failure I decided to remove this attribute.
Differential Revision: https://reviews.llvm.org/D126225
As far as I can tell, the only thing those friend classes access is the
`ValueSP` typedef.
Given that this is a map-ish class, with "Map" in its name, it doesn't
seem like a stretch to make `KeyType`, `ValueType` and `ValueSP` public.
More so when the public methods of the class have `KeyType` and
`ValueSP` arguments and clearly `ValueSP` needs to be accessed from the
outside.
`friend` complicates local reasoning about who can access private
members, which is valuable in a class like this that has every method
locking a mutex to prevent concurrent access.
Differential Revision: https://reviews.llvm.org/D126103
Register positional argument details in `CommandObjectTargetModulesList`.
I recently learned that `image list` takes a module name, but the help info
does not indicate this. With this change, `help image list` will show that it
accepts zero or more module names.
This makes it easier to get info about specific modules, without having to
find/grep through the full image list.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D125154
Ensure there's a space between "utility" and "function", and also makes
it easier to grep/search for "utility function".
While making this change, I also re-formatted the other dlopen error messages
(with clang-format). This fix other instances of spaces missing between words,
and makes each of these strings fit a single line, making them greppable.
Differential Revision: https://reviews.llvm.org/D126078
This fixes an issue that optimized variable error message is not shown to end
users in lldb-vscode.
Differential Revision: https://reviews.llvm.org/D126014
To help user identify optimized code This diff adds a "[opt]" suffix to
optimized stack frames in lldb-vscode. This provides consistent experience
as command line lldb.
It also adds a new "optimized" attribute to DAP stack frame object so that
it is easy to identify from telemetry than parsing trailing "[opt]".
Differential Revision: https://reviews.llvm.org/D126013
The previous version of this test uses mprotect, and that seemed to be
flakey on older systems. I converted the test to use the underlying
mach_vm API's. The test only runs on Darwin anyway, so this is not a
real limitation, and I'm hoping the lower level API's work more
consistently.
When the string passed to PrintCommandOutput doesn't end with a newline,
`written` will exceed `size` and result in an lldbassert.
After 8e776bb660 we don't really need
written anymore and we can check whether `str` is empty instead. This
patch simplifies the code and removes the assert that's no longer
relevant.
Differential revision: https://reviews.llvm.org/D126081
When setting an address breakpoint using a non-section address in lldb
before having ever run the program, the binary itself is not considered
a module. As a result, the breakpoint is unresolved (and never gets
resolved subsequently).
This patch changes that behavior: as a last resort, the binary is
considered as a module when resolving a non-section address breakpoint.
Differential revision: https://reviews.llvm.org/D124731
The test for commit bff4673b41 is failing on the
GreenDragon bot but none of us can repro the failure locally. Adding some logging
to the test failure to help diagnose the issue.
Report the correct register number (GENERIC_REGNUM_FLAGS) for cpsr. This
fixes TestLldbGdbServer.py on Apple Silicon.
Differential revision: https://reviews.llvm.org/D126076
A deployment target less than 10.13.4 causes an error saying that
'ptsname_r' is only available on macOS 10.13.4 or newer. The current
logic only checks if the symbol is available and doesn't account for the
deployment target. This patch fixes that by adding an availability
check.
Differential revision: https://reviews.llvm.org/D125995
This patch should fix a bug in PExpect.launch that happened when color
support is not enabled.
In that case, we need to add the `--no-use-colors` flag to lldb's launch
argument list. However, previously, each character to the string was
appended separately to the `args` list. This patch solves that by adding
the whole string to the list.
This should fix the TestIOHandlerResize failure on GreenDragon.
Differential Revision: https://reviews.llvm.org/D126021
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This is off by default. If you get a result and that
memory has memory tags, when --show-tags is given you'll
see the tags inline with the memory content.
```
(lldb) memory read mte_buf mte_buf+64 --show-tags
<...>
0xfffff7ff8020: 00 00 00 00 00 00 00 00 0d f0 fe ca 00 00 00 00 ................ (tag: 0x2)
<...>
(lldb) memory find -e 0xcafef00d mte_buf mte_buf+64 --show-tags
data found at location: 0xfffff7ff8028
0xfffff7ff8028: 0d f0 fe ca 00 00 00 00 00 00 00 00 00 00 00 00 ................ (tags: 0x2 0x3)
0xfffff7ff8038: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ (tags: 0x3 0x4)
```
The logic for handling alignments is the same as for memory read
so in the above example because the line starts misaligned to the
granule it covers 2 granules.
Depends on D125089
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D125090
This reverts commit 3e928c4b9d.
This fixes an issue seen on Windows where we did not properly
get the section names of regions if they overlapped. Windows
has regions like:
[0x00007fff928db000-0x00007fff949a0000) ---
[0x00007fff949a0000-0x00007fff949a1000) r-- PECOFF header
[0x00007fff949a0000-0x00007fff94a3d000) r-x .hexpthk
[0x00007fff949a0000-0x00007fff94a85000) r-- .rdata
[0x00007fff949a0000-0x00007fff94a88000) rw- .data
[0x00007fff949a0000-0x00007fff94a94000) r-- .pdata
[0x00007fff94a94000-0x00007fff95250000) ---
I assumed that you could just resolve the address and get the section
name using the start of the region but here you'd always get
"PECOFF header" because they all have the same start point.
The usual command repeating loop used the end address of the previous
region when requesting the next, or getting the section name.
So I've matched this in the --all scenario.
In the example above, somehow asking for the region at
0x00007fff949a1000 would get you a region that starts at
0x00007fff949a0000 but has a different end point. Using the load
address you get (what I assume is) the correct section name.
This should fix the issues introduced by d71d1a9, which skipped all the
test setup commands.
This also fixes the test failures happening in TestAutosuggestion.py.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch subtracts 1 to the pc of any frame above frame 0 to get the
previous line entry and display the right line in the debugger.
This also rephrase some old comment from `48d157dd4`.
rdar://92686666
Differential Revision: https://reviews.llvm.org/D125928
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
When the terminal window is too small, lldb would wrap progress messages
accross multiple lines which would break the progress event handling
code that is supposed to clear the message once the progress is completed.
This causes the progress message to remain on the screen, sometimes partially,
which can be confusing for the user.
To fix this issue, this patch trims the progress message to the terminal
width taking into account the progress counter leading the message for
finite progress events and also the trailing `...`.
rdar://91993836
Differential Revision: https://reviews.llvm.org/D124785
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch adds a new `use_colors` argument to the PExpect.launch
method.
As the name suggests, it allows the user to conditionally enable color
support in the debugger, which can be helpful to test functionalities that
rely on that, like progress reporting. It defaults to False.
Differential Revision: https://reviews.llvm.org/D125915
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Adrian Prantl