Commit Graph

1314 Commits

Author SHA1 Message Date
Jason Molenda 6e56c4961a Decr pc when looking for DWARF loc list entry mid-stack
When looking for a variable location in a DWARF location list,
we search the list of ranges to find one that includes the pc.
With a function mid-stack, the "pc" is the return pc instead of
the call instruction, and in optimized code this can be another
function or a different basic block (with different variable
locations).  Back up the "pc" value mid-stack to find the correct
location list entry.

Differential Revision: https://reviews.llvm.org/D124597
rdar://63903416
2022-04-29 14:34:06 -07:00
Jonas Devlieghere cbcb3bcee3
[lldb] Don't report progress in the REPL
Don't report progress events in the REPL. Most of the progress events
are debugger specific which are useful when you're debugging, but not so
much when you're waiting for the next line to be executed in the REPL.

This patch disables reporting of progress events when in REPL mode.

rdar://91502950

Differential revision: https://reviews.llvm.org/D123426
2022-04-11 13:06:40 -07:00
Jonas Devlieghere fc54427e76
[lldb] Refactor DataBuffer so we can map files as read-only
Currently, all data buffers are assumed to be writable. This is a
problem on macOS where it's not allowed to load unsigned binaries in
memory as writable. To be more precise, MAP_RESILIENT_CODESIGN and
MAP_RESILIENT_MEDIA need to be set for mapped (unsigned) binaries on our
platform.

Binaries are mapped through FileSystem::CreateDataBuffer which returns a
DataBufferLLVM. The latter is backed by a llvm::WritableMemoryBuffer
because every DataBuffer in LLDB is considered to be writable. In order
to use a read-only llvm::MemoryBuffer I had to split our abstraction
around it.

This patch distinguishes between a DataBuffer (read-only) and
WritableDataBuffer (read-write) and updates LLDB to use the appropriate
one.

rdar://74890607

Differential revision: https://reviews.llvm.org/D122856
2022-04-05 13:46:37 -07:00
Shafik Yaghmour aca9648078 [LLDB] Cleanup for Fixing DWARFExpression handling of ValueType::FileAddress case for DW_OP_deref_size
Late review on https://reviews.llvm.org/D121408 spotted some nice quick clean-ups on this code.
2022-03-24 10:00:26 -07:00
Sterling Augustine 7518e0ff63 Avoid using a variable-sized array for a tiny allocation.
Differential Revision: https://reviews.llvm.org/D121732
2022-03-15 13:00:14 -07:00
Shafik Yaghmour 6583f01707 [LLDB] Fixing DWARFExpression handling of ValueType::FileAddress case for DW_OP_deref_size
Currently DW_OP_deref_size just drops the ValueType::FileAddress case and does
not attempt to handle it. This adds support for this case and a test that
verifies this support.

I did a little refactoring since DW_OP_deref and DW_OP_deref_size have some
overlap in code.

Also see: rdar://66870821

Differential Revision: https://reviews.llvm.org/D121408
2022-03-15 09:36:20 -07:00
Shafik Yaghmour 28c878aeb2 [LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB
Applied modernize-use-default-member-init clang-tidy check over LLDB.
It appears in many files we had already switched to in class member init but
never updated the constructors to reflect that. This check is already present in
the lldb/.clang-tidy config.

Differential Revision: https://reviews.llvm.org/D121481
2022-03-14 13:32:03 -07:00
Jim Ingham 94ec0b6c5a Change "target.save-jit-objects" to "target.save-jit-objects-dir".
The old command wrote to CWD, which doesn't always work, and if it
didn't, there was no workaround (and it crashed on failure).  This
patch changed the setting to provide a directory to save the objects
to.

Differential Revision: https://reviews.llvm.org/D121036
2022-03-07 17:44:51 -08:00
Shafik Yaghmour ae869d4484 [LLDB] Remove cases of using namespace llvm:: from header file
We have using namespace llvm::dwarf in dwarf.h header globally. Replacing that
with a using namespace within lldb_private::dwarf and moving to a
using namespace lldb_private::dwarf in .cpp files and fully qualified names
in the few header files.

Differential Revision: https://reviews.llvm.org/D120836
2022-03-03 10:39:06 -08:00
Zequan Wu 15983c28aa [LLDB] Dump valid ranges of variables
This allows `image lookup -a ... -v` to print variables only if the given
address is covered by the valid ranges of the variables. Since variables created
in dwarf plugin always has empty scope range, print the variable if it has
empty scope.

Differential Revision: https://reviews.llvm.org/D119963
2022-03-02 13:44:19 -08:00
serge-sans-paille 290e482342 Cleanup LLVMDWARFDebugInfo
As usual with that header cleanup series, some implicit dependencies now need to
be explicit:

llvm/DebugInfo/DWARF/DWARFContext.h no longer includes:
- "llvm/DebugInfo/DWARF/DWARFAcceleratorTable.h"
- "llvm/DebugInfo/DWARF/DWARFCompileUnit.h"
- "llvm/DebugInfo/DWARF/DWARFDebugAbbrev.h"
- "llvm/DebugInfo/DWARF/DWARFDebugAranges.h"
- "llvm/DebugInfo/DWARF/DWARFDebugFrame.h"
- "llvm/DebugInfo/DWARF/DWARFDebugLoc.h"
- "llvm/DebugInfo/DWARF/DWARFDebugMacro.h"
- "llvm/DebugInfo/DWARF/DWARFGdbIndex.h"
- "llvm/DebugInfo/DWARF/DWARFSection.h"
- "llvm/DebugInfo/DWARF/DWARFTypeUnit.h"
- "llvm/DebugInfo/DWARF/DWARFUnitIndex.h"

Plus llvm/Support/Errc.h not included by a bunch of llvm/DebugInfo/DWARF/DWARF*.h files

Preprocessed lines to build llvm on my setup:
after: 1065629059
before: 1066621848

Which is a great diff!

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D119723
2022-02-15 09:16:03 +01:00
Nikita Popov ad1feef7b2 [lldb] Remove some uses of getPointerElementType()
While in the area, remove some uses of getPointerElementType()
that have obvious replacements.
2022-02-14 09:44:37 +01:00
Nikita Popov 2df9430fbf [lldb] Remove uses of PointerType::getElementType()
This method has been deprecated and removed. I missed these usages
in lldb previously.
2022-02-14 09:34:24 +01:00
Andy Yankovsky afb446e8a6 [lldb] Constant-resolve operands to `getelementptr`
Operands to `getelementptr` can be constants or constant expressions. Check
that all operands can be constant-resolved and resolve them during the
evaluation. If some operands can't be resolved as constants -- the expression
evaluation will fallback to JIT.

Fixes: https://bugs.llvm.org/show_bug.cgi?id=52449

Reviewed By: #lldb, shafik

Differential Revision: https://reviews.llvm.org/D113498
2022-02-09 17:38:38 +01:00
Pavel Labath c34698a811 [lldb] Rename Logging.h to LLDBLog.h and clean up includes
Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
infrastructure). This worked because Log.h included Logging.h, even
though it should.

After the recent refactor, it became impossible the two files include
each other in this direction (the opposite inclusion is needed), so this
patch removes the workaround that was put in place and cleans up all
files to include the right thing. It also renames the file to LLDBLog to
better reflect its purpose.
2022-02-03 14:47:01 +01:00
Pavel Labath a007a6d844 [lldb] Convert "LLDB" log channel to the new API 2022-02-02 14:13:08 +01:00
Pavel Labath dcd0926ad0 [lldb] Fix a couple of use-of-uninit-var errors in Materializer.cpp
These were probably not picked up before because they only run when
logging is enabled.
2022-01-26 17:01:53 +01:00
Kazu Hirata b12fd13812 Fix bugprone argument comments.
Identified by bugprone-argument-comment.
2022-01-09 12:21:02 -08:00
Kazu Hirata 2d303e6781 Remove redundant return and continue statements (NFC)
Identified with readability-redundant-control-flow.
2021-12-24 23:17:54 -08:00
Adrian Prantl 11c2af04f2 Remove redundant check (NFC) 2021-12-15 14:54:03 -08:00
Adrian Prantl 8b62429063 Use StringRef instead of char* (NFC) 2021-12-15 14:48:39 -08:00
Jonas Devlieghere 100863ccd8 [lldb] Check if language is supported before creating a REPL instance
Currently, we'll try to instantiate a ClangREPL for every known
language. The plugin manager already knows what languages it supports,
so rely on that to only instantiate a REPL when we know the requested
language is supported.

rdar://86439474

Differential revision: https://reviews.llvm.org/D115698
2021-12-14 12:05:35 -08:00
Greg Clayton 244258e35a Modify DataEncoder to be able to encode data in an object owned buffer.
DataEncoder was previously made to modify data within an existing buffer. As the code progressed, new clients started using DataEncoder to create binary data. In these cases the use of this class was possibly, but only if you knew exactly how large your buffer would be ahead of time. This patchs adds the ability for DataEncoder to own a buffer that can be dynamically resized as data is appended to the buffer.

Change in this patch:
- Allow a DataEncoder object to be created that owns a DataBufferHeap object that can dynamically grow as data is appended
- Add new methods that start with "Append" to append data to the buffer and grow it as needed
- Adds full testing of the API to assure modifications don't regress any functionality
- Has two constructors: one that uses caller owned data and one that creates an object with object owned data
- "Append" methods only work if the object owns it own data
- Removes the ability to specify a shared memory buffer as no one was using this functionality. This allows us to switch to a case where the object owns its own data in a DataBufferHeap that can be resized as data is added

"Put" methods work on both caller and object owned data.
"Append" methods work on only object owned data where we can grow the buffer. These methods will return false if called on a DataEncoder object that has caller owned data.

The main reason for these modifications is to be able to use the DateEncoder objects instead of llvm::gsym::FileWriter in https://reviews.llvm.org/D113789. This patch wants to add the ability to create symbol table caching to LLDB and the code needs to build binary caches and save them to disk.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D115073
2021-12-07 09:44:57 -08:00
Quinn Pham 04cbfa950e [lldb][NFC] Inclusive Language: rename master plan to controlling plan
[NFC] As part of using inclusive language within the llvm project, this patch
renames master plan to controlling plan in lldb.

Reviewed By: jingham

Differential Revision: https://reviews.llvm.org/D113019
2021-11-11 15:04:44 -06:00
Kazu Hirata 80e39366ee [lldb, mlir] Migrate from getNumArgOperands and arg_operands (NFC)
Note that getNumArgOperands and arg_operands are considered legacy
names.  See llvm/include/llvm/IR/InstrTypes.h for details.
2021-10-07 08:29:42 -07:00
Alex Langford 385b2189cc [lldb] Remove Expression's dependency on CPlusPlusLanguagePlugin
This change accomplishes the following:
- Moves `IRExecutionUnit::FindBestAlternateMangledName` to `Language`.
- Renames `FindBestAlternateMangledName` to
  `FindBestAlternateFunctionMangledName`
- Changes the first parameter of said method from a `ConstString`
  representing a demangled name to a `Mangled`.
- Remove the use of CPlusPlusLanguage from Expression
2021-09-29 11:39:09 -07:00
Alex Langford 4355265131 [lldb] Remove IRExecutionUnit::CollectFallbackNames
The work that IRExecutionUnit::CollectFallbackNames is basically the
work that `CPlusPlusLanguage::GetDemangledFunctionNameWithoutArguments`
does already. It's also (at time or writing) specific to C++, so it can
be folded into `IRExecutionUnit::CollectCandidateCPlusPlusNames`.

Differential Revision: https://reviews.llvm.org/D109928
2021-09-22 11:01:15 -07:00
Alex Langford a65f6aafe2 [lldb] Refactor and rename CPlusPlusLanguage::FindAlternateFunctionManglings
I have 2 goals with this change:
1. Disambiguate between CPlusPlus::FindAlternateFunctionManglings and
   IRExecutionUnit::FindBestAlternateMangledName. These are named very
   similar things, they try to do very similar things, but their
   approaches are different. This change should make it clear that one
   is generating possible alternate manglings (through some
   heuristics-based approach) and the other is finding alternate
   manglings (through searching the SymbolFile for potential matches).
2. Change GenerateAlternateFunctionManglings from a static method in
   CPlusPlusLanguage to a virtual method in Language. This will allow us
   to remove a direct use of CPlusPlusLanguage in IRExecutionUnit,
   further pushing it to be more general. This change doesn't meet this
   goal completely but allows for it to happen later.

Though this doesn't remove IRExecutionUnit's dependency on
CPlusPlusLanguage, it does bring us closer to that goal.

Differential Revision: https://reviews.llvm.org/D109785
2021-09-16 13:13:07 -07:00
Alex Langford 303b27f21b [lldb] Delete IRExecutionUnit::SearchSpec
IRExecutionUnit::SearchSpec is a struct that encapsulates information
needed to look for a symbol. Specifically, it is comprised of a name
represented with a ConstString and a FunctionNameType mask.
Because the mask is unused (effectively always set to
eFunctionNameTypeFull), we can remove the mask and replace all uses with
eFunctionNameTypeFull.  After doing that, SearchSpec is effectively a
wrapper around a ConstString.

As an aside, SearchSpec is similar in purpose to Module::LookupInfo. I
briefly considered replacing uses of SearchSpec with LookupInfo, but
the current code only cares about symbol names (treating them as
eFunctionNameTypeFull). This code does care about language type, so
LookupInfo may be appropriate for IRExecutionUnit in the future.

Differential Revision: https://reviews.llvm.org/D109384
2021-09-08 11:27:10 -07:00
Michał Górny 14735cab65 [lldb] [gdb-remote] Add eOpenOptionReadWrite for future gdb compat
Modify OpenOptions enum to open the future path into synchronizing
vFile:open bits with GDB.  Currently, LLDB and GDB use different flag
models effectively making it impossible to match bits.  Notably, LLDB
uses two bits to indicate read and write status, and uses union of both
for read/write.  GDB uses a value of 0 for read-only, 1 for write-only
and 2 for read/write.

In order to future-proof the code for the GDB variant:

1. Add a distinct eOpenOptionReadWrite constant to be used instead
   of (eOpenOptionRead | eOpenOptionWrite) when R/W access is required.

2. Rename eOpenOptionRead and eOpenOptionWrite to eOpenOptionReadOnly
   and eOpenOptionWriteOnly respectively, to make it clear that they
   do not mean to be combined and require update to all call sites.

3. Use the intersection of all three flags when matching against
   the three possible values.

This commit does not change the actual bits used by LLDB.

Differential Revision: https://reviews.llvm.org/D106984
2021-08-09 12:06:59 +02:00
Jonas Devlieghere a46bcc60e5 [lldb] Refactor IRExecutionUnit::FindInSymbols (NFC)
This patch refactors IRExecutionUnit::FindInSymbols. It eliminates a few
potential pitfalls and tries to be more explicit about the state carried
between symbol resolution attempts.

Differential revision: https://reviews.llvm.org/D107206
2021-08-05 10:18:14 -07:00
Jonas Devlieghere c020be17ce [lldb] Use a struct to pass function search options to Module::FindFunction
Rather than passing two booleans around, which is especially error prone
with them being next to each other, use a struct with named fields
instead.

Differential revision: https://reviews.llvm.org/D107295
2021-08-05 10:18:14 -07:00
Nico Weber bf3383501f [lldb] Get rid of HAVE_SYS_TYPES_H
LLVM includes this header unconditionally on all platforms
(including Windows), so this define should no longer be necessary.

No behavior change.

Differential Revision: https://reviews.llvm.org/D107338
2021-08-03 22:14:56 +02:00
Jonas Devlieghere fd2433e139 [lldb] Replace default bodies of special member functions with = default;
Replace default bodies of special member functions with = default;

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix ,

https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html

Differential revision: https://reviews.llvm.org/D104041
2021-07-02 11:31:16 -07:00
Adrian Prantl 8fb53dca2f Improve materializer error messages to include type names.
rdar://79201552
2021-06-11 17:59:00 -07:00
Jonas Devlieghere 9494c510af [lldb] Use C++11 default member initializers
This converts a default constructor's member initializers into C++11
default member initializers. This patch was automatically generated with
clang-tidy and the modernize-use-default-member-init check.

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-default-member-init' -fix

This is a mass-refactoring patch and this commit will be added to
.git-blame-ignore-revs.

Differential revision: https://reviews.llvm.org/D103483
2021-06-09 09:43:13 -07:00
Raphael Isemann 76e47d4887 [lldb][NFC] Use C++ versions of the deprecated C standard library headers
The C headers are deprecated so as requested in D102845, this is replacing them
all with their (not deprecated) C++ equivalent.

Reviewed By: shafik

Differential Revision: https://reviews.llvm.org/D103084
2021-05-26 12:46:12 +02:00
Jonas Devlieghere ce12b52de2 [lldb] Fixup more code addresses
The Swift async task pointers are signed on arm64e and we need to fixup
the addresses in the CFA and DWARF expressions.
2021-05-13 10:27:22 -07:00
Adrian Prantl 25bf137b1e Also display the underlying error message when displaying a fixit
When the user running LLDB with default settings sees the fixit
notification it means that the auto-applied fixit didn't work. This
patch shows the underlying error message instead of just the fixit to
make it easier to understand what the error in the expression was.

Differential Revision: https://reviews.llvm.org/D101333
2021-04-27 10:40:42 -07:00
Jason Molenda e9fe788d32 Target::ReadMemory read from read-only binary file Section, not memory
Commiting this patch for Augusto Noronha who is getting set
up still.

This patch changes Target::ReadMemory so the default behavior
when a read is in a Section that is read-only is to fetch the
data from the local binary image, instead of reading it from
memory.  Update all callers to use their old preferences
(the old prefer_file_cache bool) using the new API; we should
revisit these calls and see if they really intend to read
live memory, or if reading from a read-only Section would be
equivalent and important for performance-sensitive cases.

rdar://30634422

Differential revision: https://reviews.llvm.org/D100338
2021-04-16 16:13:07 -07:00
Adrian Prantl 2c6710a5e1 Teach DWARFExpression about DWARF 4+ Location Descriptions
DWARFExpression implements the DWARF2 expression model that left
ambiguity on whether the result of an expression was a value or an
address. This patch implements the DWARF location description model
introduces in DWARF 4 and sets the result Value's kind accordingly, if
the expression comes from a DWARF v4+ compile unit. The nomenclature
is taken from DWARF 5, chapter 2.6 "Location Descriptions".

Differential Revision: https://reviews.llvm.org/D98996
2021-03-23 10:29:51 -07:00
Andy Yankovsky 1b7e5d461a [lldb] Fix error message in IRInterpreter
`memory_read_error` -> `memory_write_error`

Reviewed By: teemperor

Differential Revision: https://reviews.llvm.org/D98170
2021-03-08 16:46:38 +01:00
Adrian Prantl 14ccba26bd Promote scalars to load addresses when dereferencing them.
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
2021-03-02 14:30:39 -08:00
Yuanfang Chen 5de2d189e6 [Diagnose] Unify MCContext and LLVMContext diagnosing
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
2021-03-01 15:58:37 -08:00
Jonas Devlieghere 38dfb235db [lldb] Support debugging utility functions
LLDB uses utility functions to run code in the inferior for its own
internal purposes, such as reading classes from the Objective-C runtime
for example. Because these expressions should be transparent to the
user, we ignore breakpoints and unwind the stack on errors, which
makes them hard to debug.

This patch adds a new setting target.debug-utility-expression that, when
enabled, changes these options to facilitate debugging. It enables
breakpoints, disables unwinding and writes out the utility function
source code to disk so it shows up in the source view.

Differential revision: https://reviews.llvm.org/D97249
2021-02-24 11:36:01 -08:00
Dave Lee 2a2464eb76 [lldb] Lower GetRealStopInfo into ThreadPlanCallFunction (NFC)
`GetRealStopInfo` has only one call site, and in that call site a reference to the
concrete thread plan is available (`ThreadPlanCallUserExpression`), from which
`GetRealStopInfo` can be called.

Differential Revision: https://reviews.llvm.org/D96687
2021-02-15 17:59:24 -08:00
Adrian Prantl 188b0747c1 Support dereferencing a DWARF scalar stack value
Swift async functions receive function arguments inside a
heap-allocated data structure, similar to how ObjC block captures or
C++ coroutine arguments are implement. In DWARF they are described
relative to an entry value that produces a pointer into that heap
object. At typical location looks like

DW_OP_entry_value [ DW_OP_reg14 ] DW_OP_deref DW_OP_plus_uconst 32 DW_OP_deref

This allows the unwinder (which has special ABI knowledge to restore
the contents of r14) to push the base address onto the stack thus
allowing the deref/offset operations to continue. The result of the
entry value is a scalar, because DW_OP_reg14 is a register location —
as it should be since we want to restore the pointer value contained
in r14 at the beginning of the function and not the historical memory
contents it was pointing to. The entry value should restore the
address, which is still valid, not the contents at function entry.

To make this work, we need to allow LLDB to dereference Scalar stack
results like load addresses, which is what this patch
does. Unfortunately it is difficult to test this in isolation, since
the DWARFExpression unit test doesn't have a process.

Differential Revision: https://reviews.llvm.org/D96549
2021-02-12 16:12:32 -08:00
Adrian Prantl 057efa9916 Make the error condition in Value::ValueType explicit (NFC)
The comment for ValueType claims that all values <1 are errors, but
not all switch statements take this into account. This patch
introduces an explicit Error case and deletes all default: cases, so
we get warned about incomplete switch coverage.

https://reviews.llvm.org/D96537
2021-02-12 16:12:31 -08:00
Raphael Isemann 71536fd031 [lldb] Fix that running a top level expression without a process fails with a cryptic error
Right now when running `expr --top-level -- void foo() {}`, LLDB just prints a cryptic
`error: Couldn't find $__lldb_expr() in the module` error. The reason for that is
that if we don't have a running process, we try to set our execution policy to always use the
IR interpreter (ExecutionPolicyNever) which works even without a process. However
that code didn't consider the special ExecutionPolicyTopLevel which we use for
top-level expressions. By changing the execution policy to ExecutionPolicyNever,
LLDB thinks we're actually trying to interpret a normal expression inside our
`$__lldb_expr` function and then fails when looking for it.

This just adds an exception for top-level expressions to that code and a bunch of tests.

Reviewed By: shafik

Differential Revision: https://reviews.llvm.org/D91723
2021-02-11 17:07:11 +01:00
Raphael Isemann e87b8e4498 [lldb] Log the actual expression result in UserExpression::Evaluate
This used to be a LLDB_LOGF call that used the printf %s syntax.
0ab109d43d changed it to LLDB_LOG but didn't
update this format string to use formatv's syntax so this just printed '%s'.
2021-02-11 16:15:01 +01:00