We got a bug report that this message is confusing. In this particular
case, the line zero was due to compiler tail merging (in optimized
code). The main issue was the "no source code" part: in this case it's
kind of incorrect because -- even though we can't really know that --
the address is arguably associated with *multiple* lines of source code.
I've tried to make the new wording more neutral, and added a wink
towards compiler optimizations. I left out the "compiler generated" part
of the message because I couldn't find a way to squeeze that in nicely.
I'm also not entirely sure what it was referring to -- if this was
(just) function prologue/epilogue, then maybe leaving it out is fine, as
we're not likely to stop there anyway (?)
I also left out the function name, because:
- for template functions it gets rather long
- it's already present in the message, potentially twice (once in the
"frame summary" line and once in the snippet of code we show for the
function declaration)
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
This reverts commit fd424179dc.
This patch has two problems. First, it is unnecessary, Pavel landed
a fix a week or so before mine which solves this problem in
bbd54e08b0 . Second, the fix is
incorrect; for a function above a trap handler, where all registers
are available, this patch would have lldb fetch the return address
register from frame 0. This might be 10 frames up in the stack;
the frame 0 return address register is incorrect. The change would
have been correct a short bit later than this, but Pavel's fix is
executed earlier in the function and none of this is needed.
This patch improves the formatting of editline completions. The current
implementation is naive and doesn't account for the terminal width.
Concretely, the old implementation suffered from the following issues:
- We would unconditionally pad to the longest completion. If that
completion exceeds the width of the terminal, that would result in a lot
of superfluous white space and line wrapping.
- When printing the description, we wouldn't account for the presence of
newlines, and they would continue without leading padding.
The new code accounts for both. If the completion exceeds the available
terminal width, we show what fits on the current lined followed by
ellipsis. We also no longer pad beyond the length of the current line.
Finally, we print the description line by line, with the proper leading
padding. If a line of the description exceeds the available terminal
width, we print ellipsis and won't print the next line.
Before:
```
Available completions:
_regexp-attach -- Attach to process by ID or name.
_regexp-break -- Set a breakpoint using one of several shorthand
formats.
_regexp-bt -- Show backtrace of the current thread's call sta
ck. Any numeric argument displays at most that many frames. The argument 'al
l' displays all threads. Use 'settings set frame-format' to customize the pr
inting of individual frames and 'settings set thread-format' to customize th
e thread header. Frame recognizers may filter thelist. Use 'thread backtrace
-u (--unfiltered)' to see them all.
_regexp-display -- Evaluate an expression at every stop (see 'help
target stop-hook'.)
```
After:
```
Available completions:
_regexp-attach -- Attach to process by ID or name.
_regexp-break -- Set a breakpoint using one of several shorth...
_regexp-bt -- Show backtrace of the current thread's call ...
_regexp-display -- Evaluate an expression at every stop (see 'h...
```
rdar://135818198
depends on https://github.com/llvm/llvm-project/pull/116711
[lldb] Improve rendering of inline diagnostics on the same column by
fixing the indentation and printing these annotations in the original
order.
Before
a+b+c;
^ ^ ^
| | error: 3
| |note: 2b
| error: 2a
error: 1
After
a+b+c;
^ ^ ^
| | error: 3
| error: 2a
| note: 2b
error: 1
When parsing an optimized value and reading a piece from a file address,
LLDB tries to read the data from memory using that address.
This patch converts file address to load address before reading the
memory.
Fixes#111313Fixes#97484
The motivating use case is being able to "time out" certain operations
(by adding a timed callback which will force the termination of the
loop), but the design is flexible enough to accomodate other use cases
as well (e.g. running a periodic task in the background).
The implementation builds on the existing "pending callback" mechanism,
by associating a time point with each callback -- every time the loop
wakes up, it runs all of the callbacks which are past their point, and
it also makes sure to sleep only until the next callback is scheduled to
run.
I've done some renaming as names like "TriggerPendingCallbacks" were no
longer accurate -- the function may no longer cause any callbacks to be
called (it may just cause the main loop thread to recalculate the time
it wants to sleep).
Resubmissions of https://github.com/llvm/llvm-project/pull/112596 with
buildbot fixes.
Allow LLDB to parse the dynamic symbol table from an ELF file or memory
image in an ELF file that has no section headers. This patch uses the
ability to parse the PT_DYNAMIC segment and find the DT_SYMTAB,
DT_SYMENT, DT_HASH or DT_GNU_HASH to find and parse the dynamic symbol
table if the section headers are not present. It also adds a helper
function to read data from a .dynamic key/value pair entry correctly
from the file or from memory.
This is the second half of
https://github.com/llvm/llvm-project/pull/90008.
Essentially, it replaces the work of resolving template types when we
just need the qualified names with walking the DIE tree using
`DWARFTypePrinter`.
### Result
For an internal target, the time spent on `expr *this` for the first
time reduced from 28 secs to 17 secs.
I have some reports of A/B inversion deadlocks between the
ThreadPlanStack and the StackFrameList accesses. There's a fair bit of
reasonable code in lldb that does "While accessing the ThreadPlanStack,
look at that threads's StackFrameList", and also plenty of "While
accessing the ThreadPlanStack, look at the StackFrameList."
In all the cases I've seen so far, there was at most one of the locks
taken that were trying to mutate the list, the other three were just
reading. So we could solve the deadlock by converting the two mutexes
over to shared mutexes.
This patch is the easy part, the ThreadPlanStack mutex.
The tricky part was because these were originally recursive mutexes, and
recursive access to shared mutexes is undefined behavior according to
the C++ standard, I had to add a couple NoLock variants to make sure it
didn't get used recursively. Then since the only remaining calls are out
to ThreadPlans and ThreadPlans don't have access to their containing
ThreadPlanStack, converting this to a non-recursive lock should be safe.
Allow LLDB to parse the dynamic symbol table from an ELF file or memory
image in an ELF file that has no section headers. This patch uses the
ability to parse the PT_DYNAMIC segment and find the DT_SYMTAB,
DT_SYMENT, DT_HASH or DT_GNU_HASH to find and parse the dynamic symbol
table if the section headers are not present. It also adds a helper
function to read data from a .dynamic key/value pair entry correctly
from the file or from memory.
Change the signal handler to use a pipe to notify about incoming
signals. This has two benefits:
- the signal no longer has to happen on the MainLoop thread. With the
previous implementation, this had to be the case as that was the only
way to ensure that ppoll gets interrupted correctly. In a multithreaded
process, this would mean that all other threads have to have the signal
blocked at all times.
- we don't need the android-specific workaround, which was necessary due
to the syscall being implemented in a non-atomic way
When the MainLoop class was first implemented, we did not have the
interrupt self-pipe, so syscall interruption was the most
straight-forward implementation. Over time, the class gained new
abilities (the pipe being one of them), so we can now piggy-back on
those.
This patch also changes the kevent-based implementation to use the pipe
for signal notification as well. The motivation there is slightly
different:
- it makes the implementations more uniform
- it makes sure we handle all kinds of signals, like we do with the
linux version (EVFILT_SIGNAL only catches process-directed signals)
Following up from https://github.com/llvm/llvm-project/pull/112928, we
can reuse the approach from Clang Sema to infer the MSInheritanceModel
and add the necessary attribute manually. This allows the inspection of
member function pointers with DWARF on Windows.
The class is only used from one place, which is trivial to implement
using the llvm class.
The main difference is that in the new implementation, the ranges are
parsed each time anew (instead of being parsed at startup and cached). I
believe this is fine because:
- this is already how things work with DWARF v5 debug_rnglists
- parsing debug_ranges is fairly fast (definitely faster than rnglists)
- generally, this result will be cached at a higher level anyway.
Browsing the code I did find one instance where that is not the case --
SymbolFileDWARF::ResolveFunctionAndBlock -- which is called each time we
resolve an address (to the block level). However, this function is
already pretty suboptimal: it first traverses the DIE tree (which
involves parsing all the DIE attributes) to find the correct block, then
it parses them again to construct the `lldb_private::Block`
representation, and *then* it uses the ID of the block DIE it found in
the first step to look up the `Block` object. If this turns out to be a
bottleneck, I think there are better ways to optimize it than caching
the debug_ranges parse.
The motiviation for this is that DWARFDebugRanges sorts the block
ranges, even though the order of the ranges is load-bearing (in the
absence of DW_AT_low_pc, the "base address" of a scope is determined by
the first range entry). Delaying the parsing (and sorting) step makes it
easier to access the first entry.
"statistics dump" currently report the statistics of all targets in
debugger instead of current target. This is wrong because there is a
"statistics dump --all-targets" option that supposed to include
everything.
This PR fixes the issue by only report statistics for current target
instead of all. It also includes the change to reset statistics debug
info/symbol table parsing/indexing time during debugger destroy. This is
required so that we report current statistics if we plan to reuse
lldb/lldb-dap across debug sessions
---------
Co-authored-by: jeffreytan81 <jeffreytan@fb.com>
I ran into this while look at a different bug (patch coming soon). This
function has only two callers. The first is SBTypeStaticField::GetName
(which doesn't care about templates), and the other is
CompilerDecl::GetCompilerContext (in the TypeQuery constructor), which
does want template arguments.
This function was (normally) returning the name without template args.
Since this code is only used when looking up a type in another shared
library, the odds of running into this bug are relatively low, but I add
a test to demonstrate the scenario and the fix for it nonetheless.
Amazingly (and scarily), this test actually passes without this change
in the default configuration -- and only fails with
-gsimple-template-names. The reason for that is that in the
non-simplified case we create a regular CXXRecordDecl whose name is
"bar<int>" (instead of a template record "foo" with an argument of
"int"). When evaluating the expression, we are somehow able to replace
this with a proper template specialization decl.
A scripted process implementation might return an SBMemoryRegionInfo
object in its implementation of `get_memory_region_containing_address`
which will have an address 0 and size 0, without realizing the problems
this can cause. Several algorithms in lldb will try to iterate over the
MemoryRegions of the process, starting at address 0 and expecting to
iterate up to the highest vm address, stepping by the size of each
region, so a 0-length region will result in an infinite loop. Add a
check to Process::GetMemoryRegionInfo that rejects a MemoryRegion which
does not contain the requested address; a 0-length memory region will
therefor always be rejected.
rdar://139678032
This patch is a follow-up to 9c7701fa78
and adds extra-null checks before dereferencing the inlined_info
pointer.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch moves some of the logic implemented in the SBFrame APIs to
the lldb_private::StackFrame class so it can be re-used elsewhere.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
In particular, this allows `bt -u`.
Note that this passthrough behavior has precedent in `_regexp-break`,
where `b (-.*)` is expanded to `breakpoint set %1`.
Fixes warning: cast from 'void (*)(xpc_object_t _Nonnull)' (aka 'void
(*)(NSObject<OS_xpc_object> * _Nonnull)') to 'xpc_finalizer_t' (aka
'void (*)(void * _Nullable)') converts to incompatible function type
[-Wcast-function-type-mismatch]
Add the framework code for hooking up and calling the Data Inspection
Language (DIL) implementation, as an alternate implementation for the
'frame variable' command. For now, this is an opt-in option, via a
target setting 'target.experimental.use-DIL'. See
https://discourse.llvm.org/t/rfc-data-inspection-language/69893 for more
information about this project.
This PR does not actually call any of the DIL code; instead the piece
that will eventually call the DIL code
(StackFrame::DILEvaluateVariableExpression) calls back into the original
'frame variable' implementation.
When retrieving the location of the function declaration, we were
dropping the file component on the floor, which resulted in an amusingly
confusing situation were we displayed the file containing the
implementation of the function, but used the line number of the
declaration. This patch fixes that.
It required a small refactor Function::GetStartLineSourceLineInfo to
return a SupportFile (instead of just the file spec), which in turn
necessitated changes in a couple of other places as well.
It's never set to true. Inheritable FDs are also dangerous as they can
end up processes which know nothing about them. It's better to
explicitly pass a specific FD to a specific subprocess, which we already
mostly can do using the ProcessLaunchInfo FileActions.
This is the beginning of a different, more fundamental approach to
handling. This PR tries to tries to minimize functional changes. It only
makes sure that we store the true set of ranges inside the function
object, so that subsequent patches can make use of it.
Add the ability to override the disassembly CPU and CPU features through
a target setting (`target.disassembly-cpu` and
`target.disassembly-features`) and a `disassemble` command option
(`--cpu` and `--features`).
This is especially relevant for architectures like RISC-V which relies
heavily on CPU extensions.
The majority of this patch is plumbing the options through. I recommend
looking at DisassemblerLLVMC and the test for the observable change in
behavior.
The `relative_list_list_entry_t` offset field in the Objective-C runtime
is of type `int64_t`. There are cases where these offsets are negative
values. For negative offsets, LLDB would currently incorrectly
zero-extend the offset (dropping the fact that the offset was negative),
instead producing large offsets that, when added to the
`m_baseMethods_ptr` result in addresses that had their upper bits set
(e.g., `0x00017ff81b3241b0`). We then would try to `GetMethodList` from
such an address but fail to read it (because it's an invalid address).
This would manifest in Objective-C decls not getting completed correctly
(and formatters not working). We noticed this in CI failures on our
Intel bots. This happened to work fine on arm64 because we strip the
upper bits when calling `ClassDescriptorV2::method_list_t::Read` using
the `FixCodeAddress` ABI plugin API (which doesn't do that on Intel).
The fix is to sign-extend the offset calculation.
Example failure before this patch:
```
======================================================================
FAIL: test_break_dwarf (TestRuntimeTypes.RuntimeTypesTestCase)
Test setting objc breakpoints using '_regexp-break' and 'breakpoint set'.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/michaelbuch/Git/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1769, in test_method
return attrvalue(self)
File "/Users/michaelbuch/Git/llvm-project/lldb/test/API/lang/objc/foundation/TestRuntimeTypes.py", line 48, in test_break
self.expect(
File "/Users/michaelbuch/Git/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2370, in expect
self.runCmd(
File "/Users/michaelbuch/Git/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1000, in runCmd
self.assertTrue(self.res.Succeeded(), msg + output)
AssertionError: False is not true : Got a valid type
Error output:
error: <user expression 1>:1:11: no known method '+stringWithCString:encoding:'; cast the message send to the method's return type
1 | [NSString stringWithCString:"foo" encoding:1]
| ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Config=x86_64-/Users/michaelbuch/Git/lldb-build-main-no-modules/bin/clang
---------------------------------------------------------------------- ```
Heterogenous lookups allow us to call find with StringRef, avoiding a
temporary heap allocation of std::string. Note that CommandMap just
started accepting heterogeneous lookups (#115634).
We got a bug report that the disassember output was not relocated (i.e.
a load address) for a core file (like it is for a live process). It
turns out this behavior it depends on whether the instructions were read
from an executable file or from process memory (a core file will not
typically contain the memory image for segments backed by an executable
file).
It's unclear whether this behavior is intentional, or if it was just
trying to handle the case where we're dissassembling a module without a
process, but I think it's undesirable. What makes it particularly
confusing is that the instruction addresses are relocated in this case
(unlike the when we don't have a process), so with large files and
adresses it gets very hard to see whether the relocation has been
applied or not.
This patch removes the data_from_file check so that the instruction is
relocated regardless of where it was read from. It will still not get
relocated for the raw module use case, as those can't be relocated
anywhere as they don't have a load address.
This patch adds desired feature flags in JIT compiler to enable
hard-float instructions if target supports them and allows to use floats
and doubles in lldb expressions.
Fited tests:
lldb-shell :: Expr/TestAnonNamespaceParamFunc.cpp
lldb-shell :: Expr/TestIRMemoryMap.test
lldb-shell :: Expr/TestStringLiteralExpr.test
lldb-shell :: SymbolFile/DWARF/debug-types-expressions.test
Similar as #99336
Depens on: https://github.com/llvm/llvm-project/pull/114741
Reviewed By: SixWeining
Pull Request: https://github.com/llvm/llvm-project/pull/114742
The changes in 461f859a72 (llvm/llvm-project#65974) resulted in a change
in behavior not just for completion, but also for selection of inexect
commands.
Since many use `e` to mean `expression`, this change adds an alias for
`e`. Note that the referenced change similarly aliases `h` to `help`.
In DWARF 4 and earlier `static const` members of structs, classes and
unions have an entry tag `DW_TAG_member`, and are also tagged as
`DW_AT_declaration`, but otherwise follow the same rules as
`DW_TAG_variable`.
I have to check for the sc list size being changed by the call-site
search, not just that it had more than one element.
Added a test for multiple CU's with the same name in a given module,
which would have caught this mistake.
We were also doing all the work to find call sites when the found decl
and specified decl's only difference was a column, but the incoming
specification hadn't specified a column (column number == 0).
When you set a "next branch breakpoint" and run to it while stepping,
you have to claim the stop at that breakpoint to be the top of the
inlined call stack, or you will seem to "step in" and then plans might
try to step back out again.
This records the PrefferedLineEntry for next branch breakpoints and adds
a test to make sure this works.
This reverts commit 25909b811a due to
unresolved questions about the behavior of "frame var" and ValueObject
in the presence of references (see the original patch for discussion).
Internally we use bazel in a way in which it can drop you in a LLDB
session with the target launched in a particular cwd, which is needed
for things to work. We've been making this automation work via `process
launch -w`. However, if later the user wants to restart the process with
`r`, then they end up using a different cwd for relaunching the process.
As a way to fix this, I'm adding a target-level setting that allows
configuring a default cwd used for launching the process without needing
the user to specify it manually.
Summary of Changes:
Replaced the ineffective call to `substr` with a more efficient use of
`resize` to truncate the string.
Adjusted the code to use 'resize' instead of 'substr' for better
performance and readability.
Removed unwanted file from the previous commit.
Fixes: #91209
---------
Co-authored-by: aabhinavg <tiwariabhinavak@gmail.com>
