Summary:
1. A new common completion `CommandCompletions::Breakpoints` to provide a list of the breakpoints of the current context;
2. Apply the completion above to the commands breakpoint enable/disable/delete/modify;
3. Unit test.
Reviewers: teemperor, JDevlieghere
Reviewed By: teemperor
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D79666
Summary:
`CalculateSyntheticValue` and `GetSyntheticValue` have a `use_synthetic` parameter
that makes the function do nothing when it's false. We obviously always pass true
to the function (or check that the value we pass is true), because there really isn't
any point calling with function with a `false`. This just removes all of this.
Reviewers: labath, JDevlieghere, davide
Reviewed By: davide
Subscribers: davide
Differential Revision: https://reviews.llvm.org/D79568
This was reverted due to a python2-specific bug. Re-landing with a fix
for python2.
Summary:
One small step in my long running quest to improve python exception handling in
LLDB. Replace GetInteger() which just returns an int with As<long long> and
friends, which return Expected types that can track python exceptions
Reviewers: labath, jasonmolenda, JDevlieghere, vadimcn, omjavaid
Reviewed By: labath, omjavaid
Subscribers: omjavaid, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D78462
Also, this moves numSDKs out of the actual enum, as to not mess with
the switch-cases-covered warning.
Differential Revision: https://reviews.llvm.org/D79603
Summary:
The arpa/inet.h header in macOS is providing an incorrect htonl
function with enabled local submodule visibility while building LLDB. This
caused several networking tests to fail as the IP addresses are now flipped
in LLDB.
This patch disables building with modules when local submodule visibility is
active and the current system is macOS for the source/Host directory (which
is the *only directory that includes arpa/inet.h).
* debugserver also includes arpa/inet.h but there we already disabled
modules.
Reviewers: aprantl
Reviewed By: aprantl
Subscribers: mgorny, JDevlieghere
Differential Revision: https://reviews.llvm.org/D79632
All entry points into ProcessGDBRemote that connect to the debug server
should connect to the replay server instead during reproducer replay.
This patch adds the necessary logic for ConnectRemote, which is
accessible from the SB API. This fixes active replay for
TestRecognizeBreakpoint.py as described in D78588.
Summary:
1. Created a new common completion for the registers of the current context;
2. Apply this new common completion to the commands register read/write;
3. Unit test.
Reviewers: teemperor, JDevlieghere
Reviewed By: teemperor
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D79490
We currently rely on the TypeSystem implementation to initialize this value
with 0 in the GetChildCompilerTypeAtIndex call below. Let's just initialize
this variable like the rest.
For Swift LLDB (but potentially also for module support in Clang-land)
we need a way to accumulate the path remappings produced by
Module::RegisterXcodeSDK(). In order to make this work for
SymbolFileDebugMaps, registering the search path remapping with both
modules is necessary.
Differential Revision: https://reviews.llvm.org/D79384
<rdar://problem/62750529>
When debugging a remote platform, the platform you get from
GetPlatformForArchitecture doesn't inherit from PlatformDarwin.
HostInfoMacOSX seems like the right place to have a global store of
local paths.
Differential Revision: https://reviews.llvm.org/D79364
When debugging from a SymbolMap the creation of CompileUnits for the
individual object files is so lazy that RegisterXcodeSDK() is not
invoked at all before the Swift TypeSystem wants to read it. This
patch fixes this by introducing an explicit
SymbolFile::ParseXcodeSDK() call that can be invoked deterministically
before the result is required.
<rdar://problem/62532151+62326862>
https://reviews.llvm.org/D79273
Summary:
Sometimes users think that setting a function regex for all function that contain the word 'needle' in their
name looks like this: `*needle*`. However, LLDB only searches the function name and doesn't fully match
it against the regex, so the leading and trailing '*' operators don't do anything and actually just cause the
regex engine to reject the regular expression with "repetition-operator operand invalid".
This patch makes this a bit more obvious to the user by printing a warning that a leading '*' before this
regular expression here doesn't have any purpose (and will cause an error). This doesn't attempt to detect
a case where there is only a trailing '*' as that would involve parsing the regex and it seems the most
common way to end up in this situation is by doing `rbreak *needle*`.
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D78809
Summary:
This fixes a bug where
frame var a[0]+5
returns the value a[0] without any warning because the current logic simply ignores everything after ']' as long as there is no '.', '-' or '[' in the rest of the string.
The fix simplifies the termination condition of the expression path parsing loop to check if have a non-empty remaining string to parse. Previously, the condition checked if a separator was found. That condition coincided with the remaining string-to-parse condition except for the buggy indexed case where non-empty string was left ("+5" in the example above), but the separator index was 'npos'.
Reviewed By: teemperor, labath
Differential Revision: https://reviews.llvm.org/D79404
We have the option to stop running commands in batch mode when an error
occurs. When that happens we should exit the driver with a non-zero exit
code.
Differential revision: https://reviews.llvm.org/D78825
Summary:
Languages can have different ways of formatting special characters.
E.g. when debugging C++ code a string might look like "\b", but when
debugging Swift code the same string would look like "\u{8}".
To make this work, plugins override GetStringPrinterEscapingHelper.
However, because there's a large amount of subtly divergent work done in
each override, we end up with large amounts of duplicated code. And all
the memory smashers fixed in one copy of the logic (see D73860) don't
get fixed in the others.
IMO the GetStringPrinterEscapingHelper is overly general and hard to
use. I propose deleting it and replacing it with an EscapeStyle enum,
which can be set as needed by each plugin.
A fix for some swift-lldb memory smashers falls out fairly naturally
from this deletion (https://github.com/apple/llvm-project/pull/1046). As
the swift logic becomes really tiny, I propose moving it upstream as
part of this change. I've added unit tests to cover it.
rdar://61419673
Reviewers: JDevlieghere, davide
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77843
When trying to read a core file that is not owned by the user running lldb
and that doesn't have read permission on the file, lldb shows a misleading
error message:
```
Unable to find process plug-in for core file
```
This is due to the fact that currently, lldb doesn't check the file
ownership. And when trying to to open and read a core file, the syscall
fails, which prevents a process to be created.
Since lldb already have a portable `open` syscall interface, lets take
advantage of that and delegate the error handling to the syscall
itself. This way, no matter if the file exists or if the user has proper
ownership, lldb will always try to open the file, and behave accordingly
to the error code returned.
rdar://42630030
https://reviews.llvm.org/D78712
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
The dumping code is not used by anyone, and is a source of
inconsistencies with the llvm dwarf parser, as dumping is implemented at
a different level (DWARFDie) there.
This adds an RunCommandInterpreter overload that returns an instance of
SBCommandInterpreterRunResults. The goal is to avoid having to add more
and more overloads when we need more output arguments.
Differential revision: https://reviews.llvm.org/D79120
This patch adds a new class CommandInterpreterRunResult which will be
backing the SBCommandInterpreterRunResult. It keeps track of the number
of errors as well as the result which is an enum, as proposed by Pavel
in D79120. The command interpreter now populates the results directly,
instead of its own member variables.
Differential revision: https://reviews.llvm.org/D79209
Currently, `SBCommandInterpreterRunOptions` is defined in
`SBCommandInterpreter.h`. Given that the options are always passed by
reference, a forward declaration is sufficient.
That's not the case for `SBCommandInterpreterRunResults`, which we need
for a new overload for `RunCommandInterpreter` and that returns this new
class by value. We can't include `SBCommandInterpreter.h` because
`SBCommandInterpreter::GetDebugger()` returns SBDebugger by value and
therefore needs a full definition.
This patch moves the definition of `SBCommandInterpreterRunOptions` into
a new header. In a later patch, `SBCommandInterpreterRunResults` will
be defined in there as well, solving the aforementioned problem.
Differential revision: https://reviews.llvm.org/D79115
This implements Greg's suggestion from D78825 to include "auto handle
events" and "spawn thread" in CommandInterpreterRunOptions. This change
is in preparation for adding a new overload for RunCommandInterpreter
that takes only SBCommandInterpreterRunOptions and returns
SBCommandInterpreterRunResults.
Differential revision: https://reviews.llvm.org/D79108
It seems like only the unittests are building with
BUILD_WITH_INSTALL_RPATH set to OFF. Of course when I did my last change
I only ran check-lldb-unit. Not sure why this difference exists, why
would you even install the unittest?
For the LLDB framework we do need different build and install RPATHs.
Currently that logic lives downstream. I plan to upstream that in the
near future. For now I'm just trying to make it possible to run the
test.
Summary:
This was originally commented out as it broke the data-formatter-stl/libcxx/
tests. However this was fixed by commit ef423a3ba5
(Add Objective-C property accessors loaded from Clang module DWARF to lookup)
which sets the HasExternalVisibleStorage flag for the template specializations.
Reviewers: aprantl
Reviewed By: aprantl
Subscribers: abidh, JDevlieghere
Differential Revision: https://reviews.llvm.org/D79168
The install name for the Python 3 framework in Xcode is relative to
the framework's location and not the dylib itself.
@rpath/Python3.framework/Versions/3.x/Python3
This means that we need to compute the path to the Python3.framework
and use that as the RPATH instead of the usual dylib's directory.
The cause of this crash is relatively simple -- we are using a
SymbolFileDWARFDwo to parse a (skeleton) dwarf unit. This cause the
CompileUnit to be created with the wrong ID, which later triggers an
assertion in SymbolFile::SetCompileUnitAtIndex. The fix is also simple
-- ensure we use the right symbol file for parsing.
However, a fairly elaborate setup is needed trigger this bug, because
ParseCompileUnit is normally called very early on (and with the right
symbol file object) during the process of accessing a compile unit.
The only way this can be triggered is if the DWARF unit is
"accidentally" pulled into scope during expression evaluation
This can happen if the "this" object used for the context of an
expression is in a namespace, and that namespace is also present in
other compile units
The included test recreates this setup.
Summary:
This patch adds support to access AArch64 FP SIMD core dump registers and adds a test case to verify registers.
This patches fixes a bug where doing "register read --all" causes lldb to crash.
Reviewers: labath
Reviewed By: labath
Subscribers: kristof.beyls, danielkiss, lldb-commits
Differential Revision: https://reviews.llvm.org/D77793
Summary: This patch increases maximum register size to 256 bytes to accommodate AArch64 SVE registers maximum possible size of 256 bytes.
Reviewers: labath, jankratochvil, rengolin
Reviewed By: labath
Subscribers: tschuett, kristof.beyls, danielkiss, lldb-commits
Differential Revision: https://reviews.llvm.org/D77044
Nothing guarantees that the objects in the StringMap remains at the same
address when the StringMap grows. Therefore we shouldn't return a
reference into the StringMap but return a copy of the string instead.
This method has been commented as deprecated for a while. Remove
it and replace all uses with the equivalent getCalledOperand().
I also made a few cleanups in here. For example, to removes use
of getElementType on a pointer when we could just use getFunctionType
from the call.
Differential Revision: https://reviews.llvm.org/D78882
This patch improves data formatting for CoreFoundation containers:
CFDictionary and CFSet.
These data formatters make the containers and their children appear in Xcode's
variables view (and on the command line) without having to expand the
data structure.
Previous implementation only supported showing the container's element count.
```
(lldb) frame var dict
(__NSCFDictionary *) dict = 0x00000001004062b0 2 key/value pairs
(lldb) frame var set
(__NSCFSet *) set = 0x0000000100406330 2 elements
```
Now the variable can be dereferenced to dispaly the container's children:
```
(lldb) frame var *dict
(__NSCFDictionary) *dict = {
[0] = {
key = 0x0000000100004050 @"123"
value = 0x0000000100004090 @"456"
}
[1] = {
key = 0x0000000100004030 @"abc"
value = 0x0000000100004070 @"def"
}
}
(lldb) frame var *set
(__NSCFSet) *set = {
[0] = 0x0000000100004050 @"123"
[1] = 0x0000000100004030 @"abc"
}
```
rdar://39882287
Differential Revision: https://reviews.llvm.org/D78396
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Sadly IPv6 is still not present anywhere. The test was attempting to
detect&skip such hosts, but the way it did that (essentially, by calling
getaddrinfo) meant that it only detected hosts which have IPv6 support
completely compiled out. It did not do anything about hosts which have
it compiled in, but lack runtime configuration even for the ::1 loopback
address.
This patch changes the detection logic to use a new method. It does it
by attempting to bind a socket to the appropriate loopback address. That
should ensure the hosts loopback interface is fully set up. In an effort
to avoid silently skipping the test on too many hosts, the test is
fairly strict about the kind of error it expects in these cases -- it
will only skip the test when receiving EADDRNOTAVAIL. If we find other
error codes that can be reasonably returned in these situations, we can
add more of them.
The (small) change in TCPSocket.cpp is to ensure that the code correctly
propagates the error received from the OS.
this is dead and non-functional code that hasn't been touched (modulo
refactors) since it was checked in (as an "NFC, with no review and
tests) in 2016.
Anyone interested in adding darwin support to lldb-server can look this
up in git history.
Summary:
Sometimes a result variable of some expression can be presented as an elaborated
type. In this case the methods `IsTypedefType()` and `GetTypedefedType()` of
`SBType` didn't work. This patch fixes that.
I didn't find the test for these API methods, so I added a basic test for this
too.
Reviewers: aprantl, teemperor, labath, leonid.mashinskiy
Reviewed By: teemperor
Subscribers: labath, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D78697
Summary:
Currently the breakpoint command is prompting the user to file a bug report if the provided regex is invalid:
```
(lldb) rbreak *foo
error: Function name regular expression could not be compiled: "Inconvertible error value. An error has occurred that could not be converted to a known std::error_code. Please file a bug. repetition-operator operand invalid"
```
The reason is simply that we are using the wrong StringError constructor (the one with the error code as the first parameter
is also printing the string version of the error code, and the inconvertible error code is just an invalid place holder code with
that description). Switching the StringError constructor parameters will only print the error message we get from the regex
engine when we convert the error into a string.
I checked the rest of the code base and I couldn't find the same issue anywhere else.
Fixes rdar://62233561
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D78808
For developing the OS itself there exists an "internal" variant of
each SDK. This patch adds support for these SDK directories to the
XcodeSDK class.
Differential Revision: https://reviews.llvm.org/D78675
This patch fixes a bug when synthesizing an ObjC property from
-gmodules debug info. Because the method declaration that is injected
via the non-modular property implementation is not added to the
ObjCInterfaceDecl's lookup pointer, a second copy of the accessor
would be generated when processing the ObjCPropertyDecl. This can be
avoided by finding the existing method decl in
ClangExternalASTSourceCallbacks::FindExternalVisibleDeclsByName() and
adding it to the LookupPtr.
Differential Revision: https://reviews.llvm.org/D78333
This patch ensures we don't crash in GetSoftwareBreakpointTrapOpcode for
not-yet-supported architectures but rather continue with degraded
behavior.
I found the issue in the context of an invalid ArchSpec, which should be
handled further up the chain. In this patch I've also added an assert to
cover that, so we can still catch those issues.
Differential revision: https://reviews.llvm.org/D78588
This is a code clean up of the PropertyAttributeKind and
ObjCPropertyAttributeKind enums in ObjCPropertyDecl and ObjCDeclSpec that are
exactly identical. This non-functional change consolidates these enums
into one. The changes are to many files across clang (and comments in LLVM) so
that everything refers to the new consolidated enum in DeclObjCCommon.h.
2nd Landing Attempt...
Differential Revision: https://reviews.llvm.org/D77233
Calling Disconnect while the read thread is running is racy because the
thread can also call Disconnect. This is a follow-up to b424b0bf, which
reorders other occurences of Disconnect/StopReadThread I can find, and also
adds an assertion to guard against new occurences being introduced.
Summary:
The code in DWARFCompileUnit::BuildAddressRangeTable tries hard to avoid
relying on DW_AT_low/high_pc for compile unit range information, and
this logic is a big cause of llvm/lldb divergence in the lowest layers
of dwarf parsing code.
The implicit assumption in that code is that this information (as opposed to
DW_AT_ranges) is unreliable. However, I have not been able to verify
that assumption. It is definitely not true for all present-day
compilers (gcc, clang, icc), and it was also not the case for the
historic compilers that I have been able to get a hold of (thanks Matt
Godbolt).
All compiler included in my research either produced correct
DW_AT_ranges or .debug_aranges entries, or they produced no DW_AT_hi/lo
pc at all. The detailed findings are:
- gcc >= 4.4: produces DW_AT_ranges and .debug_aranges
- 4.1 <= gcc < 4.4: no DW_AT_ranges, no DW_AT_high_pc, .debug_aranges
present. The upper version range here is uncertain as godbolt.org does
not have intermediate versions.
- gcc < 4.1: no versions on godbolt.org
- clang >= 3.5: produces DW_AT_ranges, and (optionally) .debug_aranges
- 3.4 <= clang < 3.5: no DW_AT_ranges, no DW_AT_high_pc, .debug_aranges
present.
- clang <= 3.3: no DW_AT_ranges, no DW_AT_high_pc, no .debug_aranges
- icc >= 16.0.1: produces DW_AT_ranges
- icc < 16.0.1: no functional versions on godbolt.org (some are present
but fail to compile)
Based on this analysis, I believe it is safe to start trusting
DW_AT_low/high_pc information in dwarf as well as remove the code for
manually reconstructing range information by traversing the DIE
structure, and just keep the line table fallback. The only compilers
where this will change behavior are pre-3.4 clangs, which are almost 7
years old now. However, the functionality should remain unchanged
because we will be able to reconstruct this information from the line
table, which seems to be needed for some line-tables-only scenarios
anyway (haven't researched this too much, but at least some compilers
seem to emit DW_AT_ranges even in these situations).
In addition, benchmarks showed that for these compilers computing the
ranges via line tables is noticably faster than doing so via the DIE
tree.
Other advantages include simplifying the code base, removing some
untested code (the only test changes are recent tests with overly
reduced synthetic dwarf), and increasing llvm convergence.
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D78489
Avoid a race between the Disconnect call in `Communication::ReadThread`
and the one in `Process::ShouldBroadcastEvent` by reordering the calls
to Disconnect and StopReadThread in `Process::ShouldBroadcastEvent`.
In D77295 Pavel suggested that that might explain the broken pipe I was
seeing. Indeed, changing the order resolved the issue.
Pavel Labath wrote in D73206:
The internal representation of DebugNames and Apple indexes is fixed by
the relevant (pseudo-)standards, so we can't really change it. The
question is how to efficiently (and cleanly) convert from the internal
representation to some common thing. The conversion from AppleIndex to
DIERef is trivial (which is not surprising as it was the first and the
overall design was optimized for that). With debug_names, the situation
gets more tricky. The internal representation of debug_names uses
CU-relative DIE offsets, but DIERef wants an absolute offset. That means
the index has to do more work to produce the common representation. And
it needs to do that for all results, even though a lot of the index
users are really interested only in a single entry. With the switch to
user_id_t, _all_ indexes would have to do some extra work to encode it,
only for their users to have to immediately decode it back. Having
a iterator/callback based api would allow us to minimize the impact of
that, as it would only need to happen for the entries that are really
used. And /I think/ we could make it interface returns DWARFDies
directly, and each index converts to that using the most direct approach
available.
Jan Kratochvil:
It also makes all the callers shorter as they no longer need to fetch
DWARFDIE from DIERef (and handling if not found by ReportInvalidDIERef)
but the callers are already served DWARFDIE which they need.
In some cases the DWARFDIE had to be fetched both by callee (DWARFIndex
implementation) and caller.
Differential Revision: https://reviews.llvm.org/D77970
Summary:
One small step in my long running quest to improve python exception handling in
LLDB. Replace GetInteger() which just returns an int with As<long long> and
friends, which return Expected types that can track python exceptions
Reviewers: labath, jasonmolenda, JDevlieghere, vadimcn
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D78462
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
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
Summary:
...and replace it with m_last_file_spec instead.
When Source Cache is enabled, the value stored in m_last_file_sp is
already in the Source Cache, and caching it again in SourceManager
brings no extra benefit. All we need is to "remember" the last used
file, and FileSpec can serve the same purpose.
When Source Cache is disabled, the user explicitly requested no caching
of source files, and therefore, m_last_file_sp should NOT be used.
Bug: llvm.org/PR45310
Depends on D76805.
Reviewers: labath, jingham
Reviewed By: jingham
Subscribers: labath, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76806
Summary:
Lookup and subsequent insert was done using uninitialized
FileSpec object, which caused the cache to be a no-op.
Bug: llvm.org/PR45310
Depends on D76804.
Reviewers: labath, JDevlieghere
Reviewed By: labath
Subscribers: mgorny, jingham, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76805
Summary:
LLDB memory-maps large source files, and at the same time, caches
all source files in the Source Cache.
On Windows, memory-mapped source files are not writeable, causing
bad user experience in IDEs (such as errors when saving edited files).
IDEs should have the ability to disable the Source Cache at LLDB
startup, so that users can edit source files while debugging.
Bug: llvm.org/PR45310
Reviewers: labath, JDevlieghere, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76804
Summary:
In D49685 sysroot behaviour was partially fixed. But files from local filesystem with same path still has priority over files from sysroot.
This patch fixes it by removing fallback to local filesystem from RemoteAwarePlatform::GetModuleSpec(). It is not actually required because higher level code do such fallback itself. See, for example, resolver in Platform::GetSharedModule().
Reviewers: labath, clayborg, EugeneBi
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77529
This patch threads an lldb::DescriptionLevel through the typesystem to
allow dumping the full Clang AST (level=verbose) of any lldb::Type in
addition to the human-readable source description (default
level=full). This type dumping interface is currently not exposed
through the SBAPI.
The application is to let lldb-test dump the clang AST of search
results. I need this to test lazy type completion of clang types in
subsequent patches.
Differential Revision: https://reviews.llvm.org/D78329
Summary:
The formatters code has a lot of 'reason' or 'why' values that we keep or-ing FormatterChoiceCriterion
enum values into. These values are only read by a single log statement and don't have any functional
purpose. It also seems the implementation is not finished (for example, display names and type
names don't have any dedicated enum values). Also everything is of course not tested or documented.
Let's just remove all of this.
Reviewers: labath, JDevlieghere, jingham, davide, vsk
Reviewed By: labath, vsk
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D77968
Fix a bug where UnwindAssemblyInstEmulation would confuse which
register is used to compute the Canonical Frame Address after it
had branched over a mid-function epilogue (where the CFA reg changes
from $fp to $sp in the process of epiloguing). Reinstate the
correct CFA register after we forward the unwind rule for branch
targets. The failure mode was that UnwindAssemblyInstEmulation
would think CFA was set in terms of $sp after one of these epilogues,
and if it sees modifications to $sp after the branch target, it would
change the CFA offset in the unwind rule -- even though the CFA is
defined in terms of $fp and the $sp changes are irrelevant to correct
calculation.
<rdar://problem/60300528>
Differential Revision: https://reviews.llvm.org/D78077
This is a no-op because it is set later on unconditionally again, but
it's far less confusing this way and consistent with how the setters
are initialized.
Originally committed as 416fa7720e
Reverted (due to buildbot failure - breaking lldb) in 7a45aeacf3.
I still can't seem to build lldb locally, but Pavel Labath has kindly
provided a potential fix to preserve the old behavior in lldb by
registering a simple recoverable error handler there that prints to the
desired stream in lldb, rather than stderr.
Make it possible to capture reproducers from the API test suite. Given
the symmetry between capture and replay, this patch also adds the
necessary code for replay. For now this is a NO-OP until the
corresponding reproducer instrumentation changes land.
For more info please refer to the RFC on lldb-dev:
http://lists.llvm.org/pipermail/lldb-dev/2020-April/016100.html
Differential revision: https://reviews.llvm.org/D77588
If a plan is not private, "thread plan discard" can discard it. It would
not be hard to write reliable scripted plan if its subplans could get
removed out from under it.
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.
It removes some needless deep indentation and some redundant statements.
It prepares the code for a more clean next patch - DWARF index callbacks
D77327.
Differential Revision: https://reviews.llvm.org/D77326
Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarchy in LLDB and
1;95;0csets the owning module information accordingly. My primary motivation
is to facilitate looking up per-module APINotes for individual
declarations, but this likely also has other applications.
This reapplies the previously reverted commit, but without support for
ClassTemplateSpecializations, which I'm going to look into separately.
rdar://problem/59634380
Differential Revision: https://reviews.llvm.org/D75488
Add a small artificial delay in replay mode before exiting to ensure
that all asynchronous events have completed. This should reduce the
level of replay flakiness on some of the slower bots.
The synchronization logic in the previous had a subtle bug. Moving of
the "m_read_thread_did_exit = true" into the critical section made it
possible for some threads calling SynchronizeWithReadThread call to get
stuck. This could happen if there were already past the point where they
checked this variable. In that case, they would block on waiting for the
eBroadcastBitNoMorePendingInput event, which would never come as the
read thread was blocked on getting the synchronization mutex.
The new version moves that line out of the critical section and before
the sending of the eBroadcastBitNoMorePendingInput event, and also adds
some comments to explain why the things need to be in this sequence:
- m_read_thread_did_exit = true: prevents new threads for waiting on
events
- eBroadcastBitNoMorePendingInput: unblock any current thread waiting
for the event
- Disconnect(): close the connection. This is the only bit that needs to
be in the critical section, and this is to ensure that we don't close
the connection while the synchronizing thread is mucking with it.
Original commit message follows:
Communication::SynchronizeWithReadThread is called whenever a process
stops to ensure that we process all of its stdout before we report the
stop. If the process exits, we first call this method, and then close
the connection.
However, when the child process exits, the thread reading its stdout
will usually (but not always) read an EOF because the other end of the
pty has been closed. In response to an EOF, the Communication read
thread closes it's end of the connection too.
This can result in a race where the read thread is closing the
connection while the synchronizing thread is attempting to get its
attention via Connection::InterruptRead.
The fix is to hold the synchronization mutex while closing the
connection.
I've found this issue while tracking down a rare flake in some of the
vscode tests. I am not sure this is the cause of those failures (as I
would have expected this issue to manifest itself differently), but it
is an issue nonetheless.
The attached test demonstrates the steps needed to reproduce the race.
It will fail under tsan without this patch.
Reviewers: clayborg, JDevlieghere
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77295
Summary:
Communication::SynchronizeWithReadThread is called whenever a process
stops to ensure that we process all of its stdout before we report the
stop. If the process exits, we first call this method, and then close
the connection.
However, when the child process exits, the thread reading its stdout
will usually (but not always) read an EOF because the other end of the
pty has been closed. In response to an EOF, the Communication read
thread closes it's end of the connection too.
This can result in a race where the read thread is closing the
connection while the synchronizing thread is attempting to get its
attention via Connection::InterruptRead.
The fix is to hold the synchronization mutex while closing the
connection.
I've found this issue while tracking down a rare flake in some of the
vscode tests. I am not sure this is the cause of those failures (as I
would have expected this issue to manifest itself differently), but it
is an issue nonetheless.
The attached test demonstrates the steps needed to reproduce the race.
It will fail under tsan without this patch.
Reviewers: clayborg, JDevlieghere
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77295
I fixed the bug that the "log timer" has no tab command.
Original code has the only CommandObjectLogTimer class, but it is not
sufficient. Thus I divided the content of CommandObjectLog class into
CommandObjectLogEnable class, CommandObjectLogDisable class,
CommandObjectLogDump class, CommandObjectLogReset class,
CommandObjectLogIncrement class.
Reviewed by: teemperor
Differential Revision: https://reviews.llvm.org/D76906
Summary:
This adds support for commands created through the API to support autorepeat.
This covers the case of single word and multiword commands.
Comprehensive tests are included as well.
Reviewers: labath, clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77444
Discussed on lldb-dev with Pavel Labath. This doesn't work for
background processes [causes Python to be stuck forever], and it's
unclear whether it's needed. There's no test, also. If this turns
out to be useful, it can be recommitted with a functional implementation
and a test.
We would return `LLDB_INVALID_IMAGE_TOKEN` for the address rather than
the correct value of `LLDB_IMAGE_ADDRESS`. This would result in the
check for the return value to silently pass on x64 as the invalid
address and invalid token are of different sizes (`size_t` vs
`uintprr_t`). This corrects the return value to `LLDB_INVALID_ADDRESS`
and addresses the rest to reset the mapped address to the invalid value.
This was found by inspection when trying to implement module support for
Windows.
This is mostly useful for Swift support; it allows LLDB to substitute
a matching SDK it shipped with instead of the sysroot path that was
used at compile time.
The goal of this is to make the Xcode SDK something that behaves more
like the compiler's resource directory, as in that it ships with LLDB
rather than with the debugged program. This important primarily for
importing Swift and Clang modules in the expression evaluator, and
getting at the APINotes from the SDK in Swift.
For a cross-debugging scenario, this means you have to have an SDK for
your target installed alongside LLDB. In Xcode this will always be the
case.
rdar://problem/60640017
Differential Revision: https://reviews.llvm.org/D76471
Greg Clayton a few years ago.
My patch to augment the symbol table in Mach-O files with the
dyld trie exports data structure only categorized symbols as code
or data, but Greg Clayton had a patch to do something similar to
swift a few years ago that had a more extensive categorization of
symbols, as well as extracting some objc class/ivar names from the
entries. This patch is basically just Greg's, updated a bit and
with a test case added to it.
<rdar://problem/50791451>
Differential Revision: https://reviews.llvm.org/D77369
This patch adds parts of the stack that should be useful for unwinding
to the jThreadsInfo reply from lldb-server. We return the top of the
stack (12 words), and we also try to walk the frame pointer linked list
and return the memory containing frame pointer and return address pairs.
The idea is to cover the cases with and without frame pointer omission.
Differential Revision: https://reviews.llvm.org/D74398
Summary:
Usually when Clang emits an error Fix-It it does two things. It emits the diagnostic and then it fixes the
currently generated AST to reflect the applied Fix-It. While emitting the diagnostic is easy to implement,
fixing the currently generated AST is often tricky. That causes that some Fix-Its just keep the AST as-is or
abort the parsing process entirely. Once the parser stopped, any Fix-Its for the rest of the expression are
not detected and when the user manually applies the Fix-It, the next expression will just produce a new
Fix-It.
This is often occurring with quickly made Fix-Its that are just used to bridge temporary API changes
and that often are not worth implementing a proper API fixup in addition to the diagnostic. To still
give some kind of reasonable user-experience for users that have these Fix-Its and rely on them to
fix their expressions, this patch adds the ability to retry parsing with applied Fix-Its multiple time to
give the normal Fix-It experience where things Clang knows how to fix are not causing actual expression
error (at least when automatically applying Fix-Its is activated).
The way this is implemented is just by having another setting in the expression options that specify how
often we should try applying Fix-Its and then reparse the expression. The default setting is still 1 for everyone
so this should not affect the speed in which we fail to parse expressions.
Reviewers: jingham, JDevlieghere, friss, shafik
Reviewed By: shafik
Subscribers: shafik, abidh
Differential Revision: https://reviews.llvm.org/D77214
Summary:
LLDB currently applies Fix-Its if they are attached to a Clang diagnostic that has the
severity "error". Fix-Its connected to warnings and other severities are supposed to
be ignored as LLDB doesn't seem to trust Clang Fix-Its in these situations.
However, LLDB also ignores all Fix-Its coming from "note:" diagnostics. These diagnostics
are usually emitted alongside other diagnostics (both warnings and errors), either to keep
a single diagnostic message shorter or because the Fix-It is in a different source line. As they
are technically their own (non-error) diagnostics, we currently are ignoring all Fix-Its associated with them.
For example, this is a possible Clang diagnostic with a Fix-It that is currently ignored:
```
error: <user expression 1>:2:10: too many arguments provided to function-like macro invocation
ToStr(0, {,})
^
<user expression 1>:1:9: macro 'ToStr' defined here
#define ToStr(x) #x
^
<user expression 1>:2:1: cannot use initializer list at the beginning of a macro argument
ToStr(0, {,})
^ ~~~~
```
We also don't store "note:" diagnostics at all, as LLDB's abstraction around the whole diagnostic
concept doesn't have such a concept. The text of "note:" diagnostics is instead
appended to the last non-note diagnostic (which is causing that there is no "note:" text in the
diagnostic above, as all the "note:" diagnostics have been appended to the first "error: ..." text).
This patch fixes the ignored Fix-Its in note-diagnostics by appending them to the last non-note
diagnostic, similar to the way we handle the text in these diagnostics.
Reviewers: JDevlieghere, jingham
Reviewed By: JDevlieghere
Subscribers: abidh
Differential Revision: https://reviews.llvm.org/D77055
This is a preparation for an upcoming patch which adds support for
DWARFv5 unit index sections. The patch adds tag "_EXT_" to identifiers
which reference sections that are deprecated in the DWARFv5 standard.
See D75929 for the discussion.
Differential Revision: https://reviews.llvm.org/D77141
Summary:
A recent change in ThreadPlans introduced this little compilation error.
Seems to be related to the work around https://reviews.llvm.org/D76814.
Reviewers: clayborg, labath, jingham
Reviewed By: jingham
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77450
Summary:
In this diff of mine D77186 I introduce a bug in the replace operation, where I was failing fast by mistake.
Besides, a similar problem existed in the insert-after operation, where it was failing fast.
Finally, the remove operation was wrong, as it was not using the indices provided by the users.
I fixed those issues and added some tests account for cases with multiple elements in these requests.
Reviewers: labath, clayborg
Reviewed By: labath
Subscribers: mgrang, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77324
Apparently the intention was to copy the condition above:
if (types.GetSize() >= max_matches)
break;
So that if the iteration stopped because of too many matches we do not
add even more matches in this 'Clang modules' block downward.
It was implemented by:
SymbolFileDWARF: Unconditionally scan through clang modules. NFCish
fe9eaadd68
Differential Revision: https://reviews.llvm.org/D77336
that were not reported by the OS plugin. To facilitate this, move
adding/updating the ThreadPlans for a Thread to the ThreadPlanStackMap.
Also move dumping thread plans there as well.
Added some tests for "thread plan list" and "thread plan discard" since
I didn't seem to have written any originally.
Differential Revision: https://reviews.llvm.org/D76814
It is an obvious part of D77326.
It removes some needless deep indentation and some redundant statements.
It prepares the code for a more clean next patch - DWARF index callbacks
in D77327.
LLDB relies on empty FileSpecs being invalid files, for example, they
don't exists. Currently this assumption does not always hold during
reproducer replay, because we pass the result of GetPath to the VFS.
This is an empty string, which the VFS converts to an absolute directory
by prepending the current working directory, before looking it up in the
YAML mapping. This means that an empty FileSpec will exist when the
current working directory does. This breaks at least one test
(TestAddDsymCommand.py) when ran from replay.
This patch special cases empty FileSpecs and returns a sensible result
before calling GetPath and forwarding the call.
Differential revision: https://reviews.llvm.org/D77351
This reimplements Symbols::FindSymbolFileInBundle to use the VFS-aware
recursive directory iterator. This is needed for reproducer replay.
Differential revision: https://reviews.llvm.org/D77337
The old name was a bit misleading because the functions actually return
contributions to the corresponding sections.
Differential revision: https://reviews.llvm.org/D77302
--script-language python and --script-language lua are both valid now.
Reviewed by: JDevlieghere
Differential Revision: https://reviews.llvm.org/D77241
This patch was reverted because it introduced a failure in
TestHelloWorld.py. The reason for that was running "ls" shell command
failed as it was evaluated in an environment with an empty path. This
has now been fixed with D77123, which ensures that all shell commands
inherit the host environment, so this patch should be safe to recommit.
The original commit message was:
A defensive check in ProcessLauncherWindows meant that we would never
attempt to launch a process with a completely empty environment -- the
host environment would be used instead. Instead, I make the function add
an extra null wchar_t at the end of an empty environment. The
documentation on this is a bit fuzzy, but it seems to be what is needed
to make windows accept these kinds of environments.
Reviewers: amccarth, friss
Differential Revision: https://reviews.llvm.org/D76835
Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarchy in LLDB and
sets the owning module information accordingly. My primary motivation
is to facilitate looking up per-module APINotes for individual
declarations, but this likely also has other applications.
rdar://problem/59634380
Differential Revision: https://reviews.llvm.org/D75488
Previously, this was reverted in bf65f19b becuase it checked whether
TARGET_OS_EMBEDDED is defined, but that macro is always defined.
Update the condition to check that TARGET_OS_OSX is true.
Summary:
Several lldb-vscode users have noticed that when a source map rule is invalid (because a folder doesn't exist anymore), the rest of the source maps from their configurations are not applied.
This happens because lldb-vscode executes a single "settings set target.source-map" command with all the source maps and LLDB processes them one by one until one fails.
Instead of doing this, we can process in LLDB all the source map rules and apply the valid ones instead of failing fast.
Reviewers: clayborg, labath, kusmour, aadsm
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77186
The RuntimeFunction struct, which PECallFrameInfo interprets, has a
different layout and differnet semantics on all architectures.
Differential Revision: https://reviews.llvm.org/D77000
Summary:
On most hosts we were running shell commands with an empty environment.
The only exception was windows, which was inheriting the host enviroment
mostly by accident.
Running the commands in an empty environment does not sound like a
sensible default, so this patch changes Host::RunShellCommand to inherit
the host environment. This impacts both commands run via
SBPlatform::Run (in case of host platforms), as well as the "platform
shell" CLI command.
Reviewers: jingham, friss
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77123
The FileCollector in LLDB collects every files that's used during a
debug session when capture is enabled. This ensures that the reproducer
only contains the files necessary to reproduce. This approach is not a
good fit for the dSYM bundle, which is a directory on disk, but should
be treated as a single unit.
On macOS LLDB have automatically find the matching dSYM for a binary by
its UUID. Having a incomplete dSYM in a reproducer can break debugging
even when reproducers are disabled.
This patch adds a was to specify a directory of interest to the
reproducers. It is called from SymbolVendorMacOSX with the path of the
dSYMs used by LLDB.
Differential revision: https://reviews.llvm.org/D76672
SBPlatform::GetHostPlatform was missing the reproducer instrumentation
macros. Fixed by running lldb-instr on SBPlatform.cpp:
$ ./bin/lldb-instr ../llvm-project/lldb/source/API/SBPlatform.cpp
This patch fixes a crash that happens on the DWARF expression evaluator
when trying to access the top of the stack while it's empty.
rdar://60512489
Differential Revision: https://reviews.llvm.org/D77108
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch fixes a crash that happens on the DWARF expression evaluator
when trying to access the top of the stack while it's empty.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Leverage ARM ELF build attribute section to create ELF attribute section
for RISC-V. Extract the common part of parsing logic for this section
into ELFAttributeParser.[cpp|h] and ELFAttributes.[cpp|h].
Differential Revision: https://reviews.llvm.org/D74023
The FileCollector in LLDB collects every files that's used during a
debug session when capture is enabled. This ensures that the reproducer
only contains the files necessary to reproduce. This approach is not a
good fit for the dSYM bundle, which is a directory on disk, but should
be treated as a single unit.
On macOS LLDB have automatically find the matching dSYM for a binary by
its UUID. Having a incomplete dSYM in a reproducer can break debugging
even when reproducers are disabled.
This patch adds a was to specify a directory of interest to the
reproducers. It is called from SymbolVendorMacOSX with the path of the
dSYMs used by LLDB.
Differential revision: https://reviews.llvm.org/D76672
This reverts commit because of test failures in TestHelloWorld.
It seems that this test (specifically running "ls" as a platform shell
command) depended on the implicit passing of the host environment.
The fix should be fairly simple (inherit the environment explicitly),
but it may take me a while to figure where exactly to do that. Revert
while I am figuring that out.
Summary:
A defensive check in ProcessLauncherWindows meant that we would never
attempt to launch a process with a completely empty environment -- the
host environment would be used instead. Instead, I make the function add
an extra null wchar_t at the end of an empty environment. The
documentation on this is a bit fuzzy, but it seems to be what is needed
to make windows accept these kinds of environments.
Reviewers: amccarth, friss
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76835
Summary:
D73024 seems to have fixed one set crash, but it introduced another.
Namely, if a class contains a covariant method returning itself, the
logic in MaybeCompleteReturnType could cause us to attempt a recursive
import, which would result in an assertion failure in
clang::DeclContext::removeDecl.
For some reason, this only manifested itself if the class contained at
least two member variables, and the class itself was imported as a
result of a recursive covariant import.
This patch fixes the crash by not attempting to import classes which are
already completed in MaybeCompleteReturnType. However, it's not clear to
me if this is the right fix, or if this should be handled automatically
by functions lower in the stack.
Reviewers: teemperor, shafik
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76840
LLDB only automatically applies Fix-Its from errors, but not from warnings.
Currently we only store Fix-Its from errors and then later apply all Fix-Its
we stored. This moves the filter to the application phase, so that we now
store *all* Fix-Its but only apply Fix-Its from errors later on.
This is NFC preparation for an upcoming patch.
Summary:
Currently top-level expressions won't automatically get Fix-Its applied. The reason
for that is that we only set the `m_fixed_text` member if we have a wrapping
source code (I.e. `m_source_code` is not zero and is wrapping some expressions).
This patch just always sets `m_fixed_text` to get this working.
Reviewers: labath, jingham
Reviewed By: labath
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D77042
In ObjectFileMachO we construct the symbol table from multiple
sources -- primarily the binary's nlist records, but when the nlist
symbols have been stripped, we would augment those with function
start address from the LC_FUNCTION_STARTS or eh_frame. This patch
adds another source of symbols - the exported symbols that the
dynamic linker, dyld, uses at runtime from its trie structure. This
provides us names and addresses for these functions/data.
This patch removes the code from ParseSymtab that would reject an
empty symbol table / nlist source. It adds a new symbols_added
set which tracks the address of every symbol we've added to the
symtab. We add symbols in most-information-ful order, and before
adding a symbol from less-informational-ful source (e.g.
LC_FUNCTION_STARTS with no function name), we check if that symbol
has already been added.
On targets with thumb code generation, instead of using the 0th bit
in these addresses in FunctionStarts (or now the trie entries), we
use the data field of FunctionStarts (formerly used to track if the
func_start should be added) and a flag for the trie entries to
encode this, and only store the actual addresses in the symbols_seen
and these vectors.
<rdar://problem/50791451>
Differential revision: https://reviews.llvm.org/D76758
CPlusPlusNameParser is used in several places on of them is during IR execution and setting breakpoints to pull information C++ like the basename, the context and arguments.
Currently it does not handle templated operator< properly, because of idiosyncrasy is how clang generates debug info for these cases.
It uses clang::Lexer which will tokenize operator<<A::B> into:
tok::kw_operator
tok::lessless
tok::raw_identifier
Later on the parser in ConsumeOperator() does not handle this case properly and we end up failing to parse.
Differential Revision: https://reviews.llvm.org/D76168
GetDeveloperDirectory returns a const char* which is NULL when we cannot
find the developer directory. This crashes in
PlatformDarwinKernel::CollectKextAndKernelDirectories because we're
unconditionally assigning it to a std::string. Coincidentally I just
refactored a bunch of code in PlatformMacOSX so instead of a ad-hoc fix
I've reimplemented the method based on GetXcodeContentsDirectory.
The change is mostly NFC. Obviously it fixes the crash, but it also
removes support for finding the Xcode directory through he legacy
$XCODE_SELECT_PREFIX_DIR/usr/share/xcode-select/xcode_dir_path.
Differential revision: https://reviews.llvm.org/D76938
When parsing DWARF and laying out bit-fields we currently don't take into account whether we have a base class or not.
Currently if the first field is a bit-field but the bit offset is due a field we inherit from a base class we currently
treat it as an unnamed bit-field and therefore add an extra field.
This fix will not check if we have a base class and assume that this offset is due to members we are inheriting from the base.
We are currently seeing asserts during codegen when debugging clang::DiagnosticOptions.
This assumption will fail in the case where the first field in the derived class in an unnamed bit-field. Fixing the first field
being an unnamed bit-field looks like it will require a larger change since we will need a way to track or discover the last field offset of the bases(s).
Differential Revision: https://reviews.llvm.org/D76808
In breakpad, only x86 (and mips) registers have a leading '$' in their
names. Arm architectures use plain register names.
Previously, lldb was assuming all registers have a '$'. Fix the code to
match the (unfortunately, inconsistent) reality.
Summary:
When using IPv6 host:port pairs, typically the host is put inside
brackets, such as [2601🔢...:0213]:5555, and the UriParser
can handle this format.
However, the Android infrastructure in LLDB assumes an additional
brackets around the host:port pair, such that the entire host:port
string can be treated as the host (which is used as an Android Serial
Number), and UriParser cannot handle multiple brackets. Parsing
inputs with such extra backets requires searching the closing bracket
from the right.
Test: BracketedHostnameWithPortIPv6 covers the case mentioned above
Reviewers: #lldb, labath
Reviewed By: labath
Subscribers: kwk, shafik, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76736
lldbassert is the macro that takes care of passing along line/file/function
to the lldb_assert function. Let's call that instead of manually calling the
function.
Reland with changes: the test modified in this change originally failed
on a Debian/x86_64 builder, and I suspect the cause was that lldb looked
up the line location for an artificial frame by subtracting 1 from the
frame's address. For artificial frames, the subtraction must not happen
because the address is already exact.
---
lldb currently guesses the address to use when creating an artificial
frame (i.e., a frame constructed by determining the sequence of (tail)
calls which must have happened).
Guessing the address creates problems -- use the actual address provided
by the DW_AT_call_pc attribute instead.
Depends on D76336.
rdar://60307600
Differential Revision: https://reviews.llvm.org/D76337
Summary:
Currently we only log in debug builds but I don't see why we would do this as this is neither
expensive and seems useful.
I looked into the git history of this code and it seems originally there was also an assert here
and the logging here was the #else branch branch for non-Debug builds.
Reviewers: #lldb, labath
Reviewed By: labath
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D76698
This reverts commit 6905394d15. The
changed test is failing on Debian/x86_64, possibly because lldb is
subtracting an offset from the DW_AT_call_pc address used for the
artificial frame:
http://lab.llvm.org:8011/builders/lldb-x86_64-debian/builds/7171/steps/test/logs/stdio
/home/worker/lldb-x86_64-debian/lldb-x86_64-debian/llvm-project/lldb/test/API/functionalities/tail_call_frames/unambiguous_sequence/main.cpp:6:17: error: CHECK-NEXT: expected string not found in input
// CHECK-NEXT: frame #1: 0x{{[0-9a-f]+}} a.out`func3() at main.cpp:14:3 [opt] [artificial]
^
<stdin>:3:2: note: scanning from here
frame #1: 0x0000000000401127 a.out`func3() at main.cpp:13:4 [opt] [artificial]
Summary:
These two variables are only incremented under LLDB_CONFIGURATION_DEBUG but their
value is always logged when verbose lldb formatter logging is enabled, which causes that our
cache hit/miss log looks like this in non-Debug builds:
```
Cache hits: 0 - Cache Misses: 0
...
Cache hits: 0 - Cache Misses: 0
...
Cache hits: 0 - Cache Misses: 0
```
This just always increments those two counters independent of build mode.
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D76687
Summary:
Dumping the frame using the user-set format could cause that a debug LLDB doesn't behave as a release LLDB,
which could potentially break replaying a reproducer.
Also it's kinda strange that the frame format set by the user is used in the internal log output.
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D76685
lldb currently guesses the address to use when creating an artificial
frame (i.e., a frame constructed by determining the sequence of (tail)
calls which must have happened).
Guessing the address creates problems -- use the actual address provided
by the DW_AT_call_pc attribute instead.
Depends on D76336.
rdar://60307600
Differential Revision: https://reviews.llvm.org/D76337
Summary:
This seems only useful for debugging and it's just plainly printf'ing to the console instead
of some log, so let's remove this.
Reviewers: #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D76699
Files imported by the script interpreter aren't opened by LLDB so they
don't end up in the reproducer. The solution is to explicitly add them
to the FileCollector.
Differential revision: https://reviews.llvm.org/D76626
Summary:
Detection of C strings does not work well for pointers. If the value object holding a (char*) pointer does not have an address (e.g., if it is a temp), the value is not considered a C string and its formatting is left to DumpDataExtractor rather than the special handling in ValueObject::DumpPrintableRepresentation. This leads to inconsistent outputs, e.g., in escaping non-ASCII characters. See the test for an example; the second test expectation is not met (without this patch). With this patch, the C string detection only insists that the pointer value is valid. The patch makes the code consistent with how the pointer is obtained in ValueObject::ReadPointedString.
Reviewers: teemperor
Reviewed By: teemperor
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76650
Summary:
The default behavior of Platform::PutFile is to open the file and
truncate it if it already exists. This works fine and is a sensible
default, but it interacts badly with code-signing on iOS, as doing so
invalidates the signature of the file (even if the new content has a
valid code signature).
We have a couple tests which on purpose reload a different binary with
the same name. Those tests are currently broken because of the above
interaction.
This patch simply makes the Darwin platform unconditionally delete the
destination file before sending the new one to work around this issue.
Reviewers: jasonmolenda
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76450
There an option: EvaluateExpressionOptions::SetResultIsInternal to indicate
whether the result number should be returned to the pool or not. It
got broken when the PersistentExpressionState was refactored.
This fixes the issue and provides a test of the behavior.
Differential Revision: https://reviews.llvm.org/D76532
This adds a formatter for libc++ std::unique_ptr.
I also refactored GetValueOfCompressedPair(...) out of LibCxxList.cpp since I need the same functionality and it made sense to share it.
Differential Revision: https://reviews.llvm.org/D76476
Summary:
The interactions between the environment settings (`target.env-vars`,
`target.inherit-env`) and the inferior life-cycle are non-obvious
today. For example, if `target.inherit-env` is set, the `target.env-vars`
setting will be augmented with the contents of the host environment
the first time the launch environment is queried (usually at
launch). After that point, toggling `target.inherit-env` will have no
effect as there's no tracking of what comes from the host and what is
a user setting.
This patch computes the environment every time it is queried rather
than updating the contents of the `target.env-vars` property. This
means that toggling the `target.inherit-env` property later will now
have the intended effect.
This patch also adds a `target.unset-env-vars` settings that one can
use to remove variables from the launch environment. Using this, you
can inherit all but a few of the host environment.
The way the launch environment is constructed is:
1/ if `target.inherit-env` is set, then read the host environment
into the launch environment.
2/ Remove for the environment the variables listed in
`target.unset-env`.
3/ Augment the launch environment with the contents of
`target.env-vars`. This overrides any common values with the host
environment.
The one functional difference here that could be seen as a regression
is that `target.env-vars` will not contain the inferior environment
after launch. The patch implements a better alternative in the
`target show-launch-environment` command which will return the
environment computed through the above rules.
Reviewers: labath, jingham
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76470
Summary:
When no arguments or environment is provided to SBTarget::LaunchSimple,
make it use the values surrently set in the target properties. You can
get the current behavior back by passing an empty array instead.
It seems like using the target defaults is a much more intuitive
behavior for those APIs. It's unllikely that anyone passed NULL/None to
this API after having set properties in order to explicitely ignore them.
One direct application of this change is within the testsuite. We have
plenty of tests calling LaunchSimple and passing None as environment.
If you passed --inferior-env to dotest.py to, for example, set
(DY)LD_LIBRARY_PATH, it wouldn't be taken into account.
Reviewers: jingham, labath, #libc_abi!
Subscribers: libcxx-commits, lldb-commits
Tags: #lldb, #libc_abi
Differential Revision: https://reviews.llvm.org/D76045
Summary:
The TargetProperties constructor invokes a series of callbacks to
prime the properties from the default ones. The one callback in
charge of updating the inferior environment was commented out
because it crashed.
The reason for the crash is that TargetProperties is a parent class
of Target and the callbacks were invoked using a Target that was
not fully initialized. This patch moves the initial callback
invocations to a separate function that can be called at the end
the Target constructor, thus preventing the crash.
One existing test had to be modified, because the initialization of
the environment properties now take place at the time the target is
created, not at the first use of the environment (usually launch
time).
The added test checks that the LaunchInfo object returned by
the target has been primed with the values from the settings.
Reviewers: jingham, labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76009
Summary:
LLDB keeps statistics of how many expression evaluations are 'successful' and 'failed'
which are updated after each expression evaluation (assuming statistics are enabled).
From what I understand the idea is that this could be used to define how well LLDB's
expression evaluator is working.
Currently all expressions are considered successful unless the user passes an explicit
positive element counting to the expression command (with the `-Z` flag) and then passes
an expression that successfully evaluates to a type that doesn't support element counting.
Expressions that fail to parse, execute or any other outcome are considered successful
at the moment which means we nearly always have a 100% expression evaluation
success rate.
This patch makes that expressions that fail to parse or execute to count as failed
expressions.
We can't know whether the expression failed because of an user error
of because LLDB couldn't correctly parse/compile it, but I would argue that this is
still an improvement. Assuming that the percentage of valid user expressions stays
mostly constant over time (which seems like a reasonable assumption), then this
way we can still see if we are doing relatively better/worse from release to release.
Reviewers: davide, aprantl, JDevlieghere
Reviewed By: aprantl
Subscribers: abidh
Differential Revision: https://reviews.llvm.org/D76280
Summary: Inspired by https://reviews.llvm.org/D74636, I'm introducing a basic version of Environment in the API. More functionalities can be added as needed.
Reviewers: labath, clayborg
Subscribers: mgorny, lldb-commits, diazhector98
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76111
The fourth field in the property struct is the default unsigned or enum
value for all types, except for Array and Dictionary types. For those,
it is the element type. During the tablegen conversion, this was
incorrectly translated to DefaultValueUnsigned with a value
corresponding to the OptionValue: enum type. So for
OptionValue::eTypeString this became DefaultUnsignedValue<16>. This
patch extends the tablegen backend to understand ElementType to express
this as ElementType<"String">.
Differential revision: https://reviews.llvm.org/D76535
Summary: Inspired by https://reviews.llvm.org/D74636, I'm introducing a basic version of Environment in the API. More functionalities can be added as needed.
Reviewers: labath, clayborg
Subscribers: mgorny, lldb-commits, diazhector98
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76111
Gongyu Deng