SymbolFileDWARF::ResolveSymbolContext is currently unaware that in DWARF5 the primary file is specified at file index 0. As a result it misses to correctly resolve the symbol context for the primary file when DWARF5 debug data is used and the primary file is only specified at index 0.
This change makes use of CompileUnit::ResolveSymbolContext to resolve the symbol context. The ResolveSymbolContext in CompileUnit has been previously already updated to reflect changes in DWARF5
and contains a more readable version. It can resolve more, but will also do a bit more work than
SymbolFileDWARF::ResolveSymbolContext (getting the Module, and going through SymbolFileDWARF::ResolveSymbolContextForAddress), however, it's mostly directed by $resolve_scope
what will be resolved, and ensures that code is easier to maintain if there's only one path.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D98619
In general, it seems like the debugger should allow programs to load & run with
libraries as far as possible, instead of defaulting to being super-picky about
unavailable symbols.
This is critical on macOS/Darwin, as libswiftCore.dylib may 1) export a version
symbol using @available markup and then 2) expect that other exported APIs are
only dynamically used once the version symbol is checked. We can't open a
version of the library built with a bleeding-edge SDK on an older OS without
RTLD_LAXY (or pervasive/expensive @available markup added to dyld APIs).
This was previously committed as cb8c1ee269 and reverted due to
unknown failures on the Linux bots. This version adds additional asserts
to check that the shared objects are where we expect them & that calling
f1() from libt1 produces the expected value. The Linux failure is
tracked by https://bugs.llvm.org/show_bug.cgi?id=49656.
See: https://lists.llvm.org/pipermail/lldb-dev/2021-March/016796.html
Differential Revision: https://reviews.llvm.org/D98879
In general, it seems like the debugger should allow programs to load & run with
libraries as far as possible, instead of defaulting to being super-picky about
unavailable symbols.
This is critical on macOS/Darwin, as libswiftCore.dylib may 1) export a version
symbol using @available markup and then 2) expect that other exported APIs are
only dynamically used once the version symbol is checked. We can't open a
version of the library built with a bleeding-edge SDK on an older OS without
RTLD_LAXY (or pervasive/expensive @available markup added to dyld APIs).
See: https://lists.llvm.org/pipermail/lldb-dev/2021-March/016796.html
Differential Revision: https://reviews.llvm.org/D98879
Call `os_log_fault` when an lldb assert fails. We piggyback off
`LLVM_SUPPORT_XCODE_SIGNPOSTS`, which also depends on `os_log`, to avoid
having to introduce another CMake check and corresponding define.
This patch also adds a small test using lldb-test that verifies we abort
with a "regular" assertion when asserts are enabled.
Differential revision: https://reviews.llvm.org/D98987
This reverts commit 9406d43138.
I messed up a test, and when I got it right it was failing. The changed logic
doesn't work quite right (now the async callback called at sync time is
forcing us to stop. I need to be a little more careful about that.
We weren't taking into account the "m_should_stop" setting that the
synchronous breakpoint callback had already set when we did PerformAction
in the StopInfoBreakpoint. So we didn't obey its instructions when it
told us to stop. Fixed that and added some tests both for when we
just have the setting, and when we have the setting AND other breakpoints
at the shared library load notification breakpoint address.
Differential Revision: https://reviews.llvm.org/D98914
The idiom:
```
DeclContext::lookup_result R = DeclContext::lookup(Name);
for (auto *D : R) {...}
```
is not safe when in the loop body we trigger deserialization from an AST file.
The deserialization can insert new declarations in the StoredDeclsList whose
underlying type is a vector. When the vector decides to reallocate its storage
the pointer we hold becomes invalid.
This patch replaces a SmallVector with an singly-linked list. The current
approach stores a SmallVector<NamedDecl*, 4> which is around 8 pointers.
The linked list is 3, 5, or 7. We do better in terms of memory usage for small
cases (and worse in terms of locality -- the linked list entries won't be near
each other, but will be near their corresponding declarations, and we were going
to fetch those memory pages anyway). For larger cases: the vector uses a
doubling strategy for reallocation, so will generally be between half-full and
full. Let's say it's 75% full on average, so there's N * 4/3 + 4 pointers' worth
of space allocated currently and will be 2N pointers with the linked list. So we
break even when there are N=6 entries and slightly lose in terms of memory usage
after that. We suspect that's still a win on average.
Thanks to @rsmith!
Differential revision: https://reviews.llvm.org/D91524
The functionality is not posix specific. Also force the usage of the
gdb-remote process plugin in the gdb platform class.
This is not sufficient to make TestPlatformConnect pass on windows (it
seems it suffers from module loading issues, unrelated to this test),
but it at least makes it shut down correctly, so I change the skip to an
xfail.
One of the backup schemes I use for finding kexts and kernels
on the local filesystem is to load a solitary binary when I don't
find any with a dSYM. This usually is a more confusing behavior
than helpful; people expect to get no binary loaded, or a binary
with debug information. This change stops loading kexts and
kernels that do not have an associated dSYM.
rdar://74291888
GetXcodeSDK() consistently takes over 1 second to complete if the
queried SDK is missing, because `xcrun` doesn't cache negative lookups.
Because there are multiple simulator platforms, this can add 4+ seconds
to `lldb -b some_object_file.o`.
To work around this, skip the call to GetXcodeSDK() when setting up
simulator platforms if the specified arch doesn't have what looks like a
simulator triple.
Some other ways to fix this:
- Fix caching in xcrun (rdar://74882205)
- Test for arch compat before calling SomePlatform::CreateInstance() (much
larger change)
Differential Revision: https://reviews.llvm.org/D98272
Split out the common base of Linux hardware breakpoint/watchpoint
support for AArch64 into a Utility class, and use it to implement
the matching support on FreeBSD.
Differential Revision: https://reviews.llvm.org/D96548
After 5419b67137 (which is `[SimplifyCFG] Update FoldTwoEntryPHINode to handle and/or of select and binop equally`), this uninitialized value is detected by msan.
This function would fail in debug builds, as the two usages of the
LLDB_PYTHON_RELATIVE_LIBDIR macro would expand to two distinct strings.
The path iterator macros don't support that.
Use a temporary variable to ensure everything points to a single string.
This patch exposes the getter and setter methods for the command
interpreter `print_errors` run option.
rdar://74816984
Differential Revision: https://reviews.llvm.org/D98001
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch introduces a new interpreter setting to prevent LLDB from
re-executing the previous command when passing an empty command.
This can be very useful when performing actions that requires a long
time to complete.
To preserve the original behaviour, the setting defaults to `true`.
rdar://74983516
Differential Revision: https://reviews.llvm.org/D97999
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
When using `OptionGroupPythonClassWithDict` options in an `OptionGroup`
with other `Options`, it can happen that the combinaison of some options
of each group makes the command invalid.
To solve that issue, this patch adds a bitmask argument to the
`OptionGroupPythonClassWithDict` constuctor that is used to mark each
option as required (or not).
If the `required_options` bitmask isn't passed to the constructor, the
class will keep its default behaviour, making the `--script-class` and
`--python-function` required.
rdar://65508855
Differential Revision: https://reviews.llvm.org/D97910
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
We have a plugin.process.gdb-remote.packet-timeout setting, which can be
used to control how long the lldb client is willing to wait before
declaring the server side dead. Our test suite makes use of this
feature, and sets the setting value fairly high, as the low default
value can cause flaky tests, particularly on slower bots.
After fixing TestPlatformConnect (one of the few tests exercising the
remote platform capabilities of lldb) in 4b284b9ca, it immediately
started being flaky on the arm bots. It turns out this is because the
packet-timeout setting is not being applied to platform connections.
This patch makes the platform connections also respect the value of this
setting. It also adds a test which checks that the timeout value is
being honored.
Differential Revision: https://reviews.llvm.org/D97769
Add calls into LanguageRuntime when finding the unwind method to
use out of the 0th (currently executing) stack frame.
Allow for the LanguageRuntimes to indicate if this stack frames
should be treated like a zeroth-frame -- symbolication should be
done based on the saved pc address, not decremented like normal ABI
function calls.
Add methods to RegisterContext and StackFrame to get a pc value
suitable for symbolication, to reduce the number of places in lldb
where we decrement the saved pc values before symbolication.
<rdar://problem/70398009>
Differential Revision: https://reviews.llvm.org/D97644
Apply changes from https://reviews.llvm.org/D91014 to other places where DWARF entries are being processed.
Test case is provided by @jankratochvil.
The test is marked to run only on x64 and exclude Windows and Darwin, because the assembly is not OS-independent.
(First attempt https://reviews.llvm.org/D96778 broke the build bots)
Reviewed By: jankratochvil
Differential Revision: https://reviews.llvm.org/D97765
A few cleanups suggested in another patch review's comments:
1. Use llvm:unique_function for storing & invoking callbacks from
Editline to IOHandler
2. Change return type of one of the callback setters from bool to void,
since it's return value was never used
3. Moved the callback setters inline & made them nonstatic, since that's
more consistent with other setter definitions
4. Removed the baton parameter since we no longer need it anymore
Differential revision: https://reviews.llvm.org/D50299
This is a follow-up to 188b0747c1. This
is a very narrow fix to a more general problem. LLDB should be better
at distinguishing between implict and memory location descriptions.
rdar://74902042
GDB remote protocol does not specify length of g packet for register read. It depends on remote to include all or exclude certain registers from g packet. In case a register or set of registers is not included as part of g packet then we should fall back to p packet for reading all registers excluded from g packet by remote. This patch adds support for above feature and adds a test-case for the same.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D97498
The situation with inline asm/MC error reporting is kind of messy at the
moment. The errors from MC layout are not reliably propagated and users
have to specify an inlineasm handler separately to get inlineasm
diagnose. The latter issue is not a correctness issue but could be improved.
* Kill LLVMContext inlineasm diagnose handler and migrate it to use
DiagnoseInfo/DiagnoseHandler.
* Introduce `DiagnoseInfoSrcMgr` to diagnose SourceMgr backed errors. This
covers use cases like inlineasm, MC, and any clients using SourceMgr.
* Move AsmPrinter::SrcMgrDiagInfo and its instance to MCContext. The next step
is to combine MCContext::SrcMgr and MCContext::InlineSrcMgr because in all
use cases, only one of them is used.
* If LLVMContext is available, let MCContext uses LLVMContext's diagnose
handler; if LLVMContext is not available, MCContext uses its own default
diagnose handler which just prints SMDiagnostic.
* Change a few clients(Clang, llc, lldb) to use the new way of reporting.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D97449
These warnings are raised when compiling with gcc due to either having too few or too many commas, or in the case of lldb, the possibility of a nullptr.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D97586
This patch introduces Scripted Processes to lldb.
The goal, here, is to be able to attach in the debugger to fake processes
that are backed by script files (in Python, Lua, Swift, etc ...) and
inspect them statically.
Scripted Processes can be used in cooperative multithreading environments
like the XNU Kernel or other real-time operating systems, but it can
also help us improve the debugger testing infrastructure by writting
synthetic tests that simulates hard-to-reproduce process/thread states.
Although ScriptedProcess is not feature-complete at the moment, it has
basic execution capabilities and will improve in the following patches.
rdar://65508855
Differential Revision: https://reviews.llvm.org/D95713
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch adds a ScriptedProcess interface to the ScriptInterpreter and
more specifically, to the ScriptInterpreterPython.
This interface will be used in the C++ `ScriptProcess` Process Plugin to
call the script methods.
At the moment, not all methods are implemented, they will upstreamed in
upcoming patches.
This patch also adds helper methods to the ScriptInterpreter to
convert `SBAPI` Types (SBData & SBError) to `lldb_private` types
(DataExtractor & Status).
rdar://65508855
Differential Revision: https://reviews.llvm.org/D95711
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch adds a new command options to the CommandObjectProcessLaunch
for scripted processes.
Among the options, the user need to specify the class name managing the
scripted process. The user can also use a key-value dictionary holding
arbitrary data that will be passed to the managing class.
This patch also adds getters and setters to `SBLaunchInfo` for the
class name managing the scripted process and the dictionary.
rdar://65508855
Differential Review: https://reviews.llvm.org/D95710
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Kim-Anh Tran