| Age | Commit message (Collapse) | Author |
|---|
|
The Transactional Memory Extension (TME) was introduced as part of
Armv9-A but has not been adopted by the ecosystem. This mirrors what
Arm has observed with similar extensions in other architectures.
Therefore, remove FEAT_TME assembly and ACLE code from llvm, because
support for TME has now been officially withdrawn, as noted here:
```
FEAT_TME is withdrawn from all future versions of Arm®
Architecture Reference Manual for A-profile architecture.
```
referenced in Known Issue D24093, documented here:
https://developer.arm.com/documentation/102105/lb-05/
|
|
Otherwise these tests are reliant on the compiler defaulting to having the extensions on.
Rest of LLVM's codebase doesn't seem to make such assumptions.
Tested by building with `-std=c2y` in Clang's C frotend's config file.
|
|
Most of the cases were where a C++ file was being compiled with the C substitution.
There were a few cases of the opposite though.
LLDB seems to be the only real culprit in the LLVM codebase for these mismatches.
Rest of the LLVM presumably sticks at least language-specific options in the common substitutions
making the mistakes immediately apparent.
I found these by using Clang frontend configuration files containing language-specific options for
both C and C++ (e.g. `-std=c2y` and `-std=c++26`).
|
|
This patch causes the various AST dump commands (`target modules dump
ast`/`target dump typesystem`) to be color-highlighted. I added a `bool
show_color` parameter to `SymbolFile::DumpClangAST` and
`TypeSystem::Dump`. In `TypeSystemClang` I temporarily sets the
`getShowColors` flag on the owned Clang AST (using an RAII helper) for
the duration of the AST dump. We use `Debugger::GetUseColors` to decide
whether to color the AST dump.
|
|
%T has been deprecated for about seven years, mostly because it is not
unique to each test which can lead to races. This patch updates the few
remaining tests in lldb that use %T to not use it (either directly using
files or creating their own temp dir). The eventual goal is to remove
support for %T from llvm-lit given few tests use it and it still has
racey behavior.
This patch errors on the side of creating new temp dirs even when not
strictly necessary to avoid needing to update filenames inside filecheck
matchers.
|
|
This changes the example command added in
https://github.com/llvm/llvm-project/pull/145793 so that the fdis
program does not have to be a single program name.
Doing so also means we can run the test on Windows where the program
needs to be "python.exe script_name".
I've changed "fdis set" to treat the rest of the command as the program.
Then store that as a list to be passed to subprocess. If we just use a
string, Python will think that "python.exe foo" is the name of an actual
program instead of a program and an argument to it.
This will still break if the paths have spaces in, but I'm trying to do
just enough to fix the test here without rewriting all the option
handling.
|
|
Added by https://github.com/llvm/llvm-project/pull/145793
Failing on our Windows on Arm bot:
https://github.com/llvm/llvm-project/pull/145793
Shebang lines don't work on Windows and we can't pass "python script_name"
to the "fdis set" commadn because of the way arguments are parsed currently.
I can fix that but that needs review, disable the test for now.
|
|
LLDB uses the LLVM disassembler to determine the size of instructions and
to do the actual disassembly. Currently, if the LLVM disassembler can't
disassemble an instruction, LLDB will ignore the instruction size, assume
the instruction size is the minimum size for that device, print no useful
opcode, and print nothing for the instruction.
This patch changes this behavior to separate the instruction size and
"can't disassemble". If the LLVM disassembler knows the size, but can't
dissasemble the instruction, LLDB will use that size. It will print out
the opcode, and will print "<unknown>" for the instruction. This is much
more useful to both a user and a script.
The impetus behind this change is to clean up RISC-V disassembly when
the LLVM disassembler doesn't understand all of the instructions.
RISC-V supports proprietary extensions, where the TD files don't know
about certain instructions, and the disassembler can't disassemble them.
Internal users want to be able to disassemble these instructions.
With llvm-objdump, the solution is to pipe the output of the disassembly
through a filter program. This patch modifies LLDB's disassembly to look
more like llvm-objdump's, and includes an example python script that adds
a command "fdis" that will disassemble, then pipe the output through a
specified filter program. This has been tested with crustfilt, a sample
filter located at https://github.com/quic/crustfilt .
Changes in this PR:
- Decouple "can't disassemble" with "instruction size".
DisassemblerLLVMC::MCDisasmInstance::GetMCInst now returns a bool for
valid disassembly, and has the size as an out paramter.
Use the size even if the disassembly is invalid.
Disassemble if disassemby is valid.
- Always print out the opcode when -b is specified.
Previously it wouldn't print out the opcode if it couldn't disassemble.
- Print out RISC-V opcodes the way llvm-objdump does.
Code for the new Opcode Type eType16_32Tuples by Jason Molenda.
- Print <unknown> for instructions that can't be disassembled, matching
llvm-objdump, instead of printing nothing.
- Update max riscv32 and riscv64 instruction size to 8.
- Add example "fdis" command script.
- Added disassembly byte test for x86 with known and unknown instructions.
- Added disassembly byte test for riscv32 with known and unknown instructions,
with and without filtering.
- Added test from Jason Molenda to RISC-V disassembly unit tests.
|
|
continuation of
[#142684](https://github.com/llvm/llvm-project/pull/142684) to show
plugin names.
From issue [#14258](https://github.com/llvm/llvm-project/issues/142581)
|
|
In #134418 we added support to list/enable/disable `SystemRuntime` and
`InstrumentationRuntime` plugins. We limited it to those two plugin
types to flesh out the idea with a smaller change.
This PR adds support for the remaining plugin types. We now support all
the plugins that can be registered directly with the plugin manager.
Plugins that are added by loading shared objects are still not
supported.
|
|
This commit adds three new commands for managing plugins. The `list`
command will show which plugins are currently registered and their
enabled state. The `enable` and `disable` commands can be used to enable
or disable plugins.
A disabled plugin will not show up to the PluginManager when it iterates
over available plugins of a particular type.
The purpose of these commands is to provide more visibility into
registered plugins and allow users to disable plugins for experimental
perf reasons.
There are a few limitations to the current implementation
1. Only SystemRuntime and InstrumentationRuntime plugins are currently
supported. We can easily extend the existing implementation to support
more types. The scope was limited to these plugins to keep the PR size
manageable.
2. Only "statically" know plugin types are supported (i.e. those managed
by the PluginManager and not from `plugin load`). It is possibly we
could support dynamic plugins as well, but I have not looked into it
yet.
|
|
Fixes #142581
|
|
Again I think this requires DWARF. In theory we could use the PDB
file but I suspect that PDB file is in fact empty, because we
tell clang to produce DWARF.
So on Windows, first thing is we cannot run the expressions:
(lldb) expr A(); A1(); BA1(); AB();
error: <user expression 1>:1:1: 'A' has unknown return type; cast the call to its declared return type
1 | A(); A1(); BA1(); AB();
| ^~~
...and so on...
And then the AST is all unknown functions:
(lldb) image dump ast
Dumping clang ast for 4 modules.
TranslationUnitDecl 0x2b3bb591870 <<invalid sloc>> <invalid sloc> <undeserialized declarations>
|-FunctionDecl 0x2b3bb592970 <<invalid sloc>> <invalid sloc> mainCRTStartup 'unsigned long (void *)'
| `-ParmVarDecl 0x2b3bb592a20 <<invalid sloc>> <invalid sloc> 'void *'
`-FunctionDecl 0x2b3bb592ad8 <<invalid sloc>> <invalid sloc> __scrt_common_main_seh 'int ()' static
So I'm just going to disable this test on Windows, it's pretty
clear why it doesn't work and we have no plans to make it work.
|
|
Depends on https://github.com/llvm/llvm-project/pull/142163
This patch makes the `-ast-dump-filter` Clang option available to the
`target modules dump ast` command. This allows us to selectively dump
parts of the AST by name.
The AST can quickly grow way too large to skim on the console. This will
aid in debugging AST related issues.
Example:
```
(lldb) target modules dump ast --filter func
Dumping clang ast for 48 modules.
Dumping func:
FunctionDecl 0xc4b785008 <<invalid sloc>> <invalid sloc> func 'void (int)' extern
|-ParmVarDecl 0xc4b7853d8 <<invalid sloc>> <invalid sloc> x 'int'
`-AsmLabelAttr 0xc4b785358 <<invalid sloc>> Implicit "_Z4funcIiEvT_"
Dumping func<int>:
FunctionDecl 0xc4b7850b8 <<invalid sloc>> <invalid sloc> func<int> 'void (int)' implicit_instantiation extern
|-TemplateArgument type 'int'
| `-BuiltinType 0xc4b85b110 'int'
`-ParmVarDecl 0xc4b7853d8 <<invalid sloc>> <invalid sloc> x 'int'
```
The majority of this patch is adjust the `Dump` API. The main change in
behaviour is in `TypeSystemClang::Dump`, where we now use the
`ASTPrinter` for dumping the `TranslationUnitDecl`. This is where the
`-ast-dump-filter` functionality lives in Clang.
|
|
|
|
|
|
(#140585)
because output-redirection doesn't work properly
|
|
Given this simple test case:
```
// foo.h
extern int* ptr;
inline void g(int x) {
*ptr = x; // should raise a SIGILL
}
//--------------
// foo.cc
#include "foo.h"
int* ptr;
//--------------
// main.cc
#include "foo.h"
int main() {
g(123); // Call the inlined function and crash
return 0;
}
$ clang -g main.cc foo.cc -o main.out
$ lldb main.out
```
When you run `main.out` under lldb, it'd stop inside `void g(int)`
because of the crash.
The stack trace would show that it had crashed in `foo.h`, but if you do
`list foo.h:2`, lldb would complain that it could not find the source
file, which is confusing.
This patch make `list` work with headers.
|
|
Added in https://github.com/llvm/llvm-project/pull/137515,
as the source uses unistd.h which isn't present there.
| C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\Shell\Commands/Inputs/sigchld.c:4:10: fatal error: 'unistd.h' file not found
| 4 | #include <unistd.h>
| | ^~~~~~~~~~
| 1 error generated.
|
|
(#137515)
|
|
Continuing the theme from #116777 and #124931, this patch ensures we
compute the correct address when a functions is spread across multiple
sections. Due to this, it's not sufficient to adjust the offset in the
section+offset pair (Address::Slide). We must actually slide the file
offset and then recompute the section using the result.
I found this out due to a failure to disassemble some parts of the
function, so I'm testing with that, although it's likely there are other
things that were broken due to this.
|
|
Identical PR to: https://github.com/llvm/llvm-project/pull/134563
Previous PR was approved and landed but broke the build due to bad
merge.
Manually resolve the merge conflict and try to land again.
Co-authored-by: George Hu <georgehuyubo@gmail.com>
|
|
This reverts commit 070a4ae2f9bcf6967a7147ed2972f409eaa7d3a6.
Multiple buildbot failures have been reported:
https://github.com/llvm/llvm-project/pull/134563
The build fails with:
lldb/source/Target/Statistics.cpp:75:39: error: use of undeclared
identifier 'num_symbols_loaded'
|
|
In statistics, add locate time for each module in statistics, we time
the PluginManager::LocateExecutableSymbolFile and
PluginManager::LocateExecutableObjectFile call, save the duration for
the succeeded symbol locator plugin in the Module class as a map.
New key being added:
Module level: "_symbolLocatorTime_"
Summary level: "_totalSymbolLocatorTime_"
which would be a map of symbol_locator_plugin_name to time.
Sample statistic dump output after this change:
```
Command: statistics dump
===============Output===============
{
"commands": {
"command container add": 1,
"command script add": 51,
"command script import": 59,
"statistics dump": 1,
"target create": 1,
"type summary add": 36,
"type synthetic add": 21
},
"memory": {
"strings": {
"bytesTotal": 2801664,
"bytesUnused": 1704256,
"bytesUsed": 1097408
}
},
"modules": [
{
"debugInfoByteSize": 244927,
"debugInfoEnabled": true,
"debugInfoHadIncompleteTypes": false,
"debugInfoHadVariableErrors": false,
"debugInfoIndexLoadedFromCache": false,
"debugInfoIndexSavedToCache": false,
"debugInfoIndexTime": 0.61934599999999995,
"debugInfoParseTime": 0.00033100000000000002,
"identifier": 94868115726768,
"path": "/home/hyubo/.cache/llvm-debuginfod/client/llvmcache-720c9a0f5ba8b460a1524a25597226f0fa551f71-c4crasher",
"symbolLocatorTime": {
"debuginfod": 1.4547020000000002
},
"symbolTableIndexTime": 0.0035370000000000002,
"symbolTableLoadedFromCache": false,
"symbolTableParseTime": 0.0055040000000000002,
"symbolTableSavedToCache": false,
"symbolTableStripped": false,
"triple": "x86_64--linux",
"uuid": "720C9A0F-5BA8-B460-A152-4A25597226F0-FA551F71"
},
{
"debugInfoByteSize": 0,
"debugInfoEnabled": false,
"debugInfoHadIncompleteTypes": false,
"debugInfoHadVariableErrors": false,
"debugInfoIndexLoadedFromCache": false,
"debugInfoIndexSavedToCache": false,
"debugInfoIndexTime": 0,
"debugInfoParseTime": 0,
"identifier": 94868111142256,
"path": "[vdso](0x00007ffd41c59000)",
"symbolLocatorTime": {
"debuginfod": 0.80597700000000005
},
"symbolTableIndexTime": 2.8e-05,
"symbolTableLoadedFromCache": false,
"symbolTableParseTime": 0.00037300000000000001,
"symbolTableSavedToCache": false,
"symbolTableStripped": false,
"triple": "x86_64--linux",
"uuid": "4D1F38BD-BD34-DFB3-C9A5-B49A2A912219-AC713763"
},
{
"debugInfoByteSize": 0,
"debugInfoEnabled": false,
"debugInfoHadIncompleteTypes": false,
"debugInfoHadVariableErrors": false,
"debugInfoIndexLoadedFromCache": false,
"debugInfoIndexSavedToCache": false,
"debugInfoIndexTime": 0,
"debugInfoParseTime": 0,
"identifier": 94868116162096,
"path": "/usr/local/fbcode/platform010/lib/libc.so.6",
"symbolLocatorTime": {
"debuginfod": 0.286356
},
"symbolTableIndexTime": 0.0091780000000000004,
"symbolTableLoadedFromCache": false,
"symbolTableParseTime": 0.081841999999999998,
"symbolTableSavedToCache": false,
"symbolTableStripped": false,
"triple": "x86_64--linux",
"uuid": "ACE9DF01-8872-3A35-6D14-3C92527EF739-4BE32C75"
},
{
"debugInfoByteSize": 0,
"debugInfoEnabled": false,
"debugInfoHadIncompleteTypes": false,
"debugInfoHadVariableErrors": false,
"debugInfoIndexLoadedFromCache": false,
"debugInfoIndexSavedToCache": false,
"debugInfoIndexTime": 0,
"debugInfoParseTime": 0,
"identifier": 94868111990032,
"path": "/usr/local/fbcode/platform010/lib/libm.so.6",
"symbolLocatorTime": {
"debuginfod": 0.63356699999999999
},
"symbolTableIndexTime": 0.0023960000000000001,
"symbolTableLoadedFromCache": false,
"symbolTableParseTime": 0.021706,
"symbolTableSavedToCache": false,
"symbolTableStripped": false,
"triple": "x86_64--linux",
"uuid": "85932B54-0DE7-4FC1-23B0-FB09AD1A5A61-8E1098B7"
},
{
"debugInfoByteSize": 0,
"debugInfoEnabled": false,
"debugInfoHadIncompleteTypes": false,
"debugInfoHadVariableErrors": false,
"debugInfoIndexLoadedFromCache": false,
"debugInfoIndexSavedToCache": false,
"debugInfoIndexTime": 0,
"debugInfoParseTime": 0,
"identifier": 94868116399488,
"path": "/usr/local/fbcode/platform010/lib/libmvec.so.1",
"symbolLocatorTime": {
"debuginfod": 0.66705099999999995
},
"symbolTableIndexTime": 0.00053700000000000004,
"symbolTableLoadedFromCache": false,
"symbolTableParseTime": 0.0034429999999999999,
"symbolTableSavedToCache": false,
"symbolTableStripped": false,
"triple": "x86_64--linux",
"uuid": "4537CA22-8E6E-495B-7A03-FC2CEDCAD71C-8A7B2067"
},
{
"debugInfoByteSize": 0,
"debugInfoEnabled": false,
"debugInfoHadIncompleteTypes": false,
"debugInfoHadVariableErrors": false,
"debugInfoIndexLoadedFromCache": false,
"debugInfoIndexSavedToCache": false,
"debugInfoIndexTime": 0,
"debugInfoParseTime": 0,
"identifier": 94868111778368,
"path": "/usr/local/fbcode/platform010/lib/libatomic.so.1",
"symbolLocatorTime": {
"debuginfod": 0.83268299999999995
},
"symbolTableIndexTime": 0.000243,
"symbolTableLoadedFromCache": false,
"symbolTableParseTime": 0.0026640000000000001,
"symbolTableSavedToCache": false,
"symbolTableStripped": false,
"triple": "x86_64--",
"uuid": "F90F9111-BBD1-C2A9-972A-34EB75ABE62E-3BDED9CF"
},
{
"debugInfoByteSize": 0,
"debugInfoEnabled": false,
"debugInfoHadIncompleteTypes": false,
"debugInfoHadVariableErrors": false,
"debugInfoIndexLoadedFromCache": false,
"debugInfoIndexSavedToCache": false,
"debugInfoIndexTime": 0,
"debugInfoParseTime": 0,
"identifier": 94868116403264,
"path": "/usr/local/fbcode/platform010/lib/libgcc_s.so.1",
"symbolLocatorTime": {
"debuginfod": 0.58871499999999999
},
"symbolTableIndexTime": 0.000292,
"symbolTableLoadedFromCache": false,
"symbolTableParseTime": 0.0033,
"symbolTableSavedToCache": false,
"symbolTableStripped": false,
"triple": "x86_64--",
"uuid": "1C715A92-40BE-BE95-E148-1B401749BAB8-15D09F9D"
},
{
"debugInfoByteSize": 0,
"debugInfoEnabled": false,
"debugInfoHadIncompleteTypes": false,
"debugInfoHadVariableErrors": false,
"debugInfoIndexLoadedFromCache": false,
"debugInfoIndexSavedToCache": false,
"debugInfoIndexTime": 0,
"debugInfoParseTime": 0,
"identifier": 94868113225328,
"path": "/usr/local/fbcode/platform010/lib/libstdc++.so.6",
"symbolLocatorTime": {
"debuginfod": 0.76993400000000001
},
"symbolTableIndexTime": 0.042455,
"symbolTableLoadedFromCache": false,
"symbolTableParseTime": 0.081374000000000002,
"symbolTableSavedToCache": false,
"symbolTableStripped": false,
"triple": "x86_64--",
"uuid": "C9DAEE53-F607-981B-6BED-F2042833BFC7-71A1E66C"
},
{
"debugInfoByteSize": 0,
"debugInfoEnabled": false,
"debugInfoHadIncompleteTypes": false,
"debugInfoHadVariableErrors": false,
"debugInfoIndexLoadedFromCache": false,
"debugInfoIndexSavedToCache": false,
"debugInfoIndexTime": 0,
"debugInfoParseTime": 0,
"identifier": 94868113600960,
"path": "/usr/local/fbcode/platform010/lib/ld.so",
"symbolLocatorTime": {
"debuginfod": 0.48382199999999997
},
"symbolTableIndexTime": 0.00054799999999999998,
"symbolTableLoadedFromCache": false,
"symbolTableParseTime": 0.0057219999999999997,
"symbolTableSavedToCache": false,
"symbolTableStripped": false,
"triple": "x86_64--linux",
"uuid": "CCA86CF4-E4FF-42C8-7056-2F7D8B83AEE0-530B4095"
}
],
"targets": [
{
"breakpoints": [],
"dyldPluginName": "dump-modulelist-dyld",
"expressionEvaluation": {
"failures": 0,
"successes": 0
},
"frameVariable": {
"failures": 0,
"successes": 0
},
"mismatchCoredumpModuleCount": 0,
"moduleIdentifiers": [
94868115726768,
94868111142256,
94868116162096,
94868111990032,
94868116399488,
94868111778368,
94868116403264,
94868113225328,
94868113600960
],
"signals": [
{
"SIGABRT": 1
}
],
"sourceMapDeduceCount": 0,
"sourceRealpathAttemptCount": 0,
"sourceRealpathCompatibleCount": 0,
"stopCount": 1,
"summaryProviderStatistics": [],
"targetCreateTime": 4.1999999999999998e-05,
"totalBreakpointResolveTime": 0,
"totalSharedLibraryEventHitCount": 0
}
],
"totalDebugInfoByteSize": 244927,
"totalDebugInfoEnabled": 1,
"totalDebugInfoIndexLoadedFromCache": 0,
"totalDebugInfoIndexSavedToCache": 0,
"totalDebugInfoIndexTime": 0.61934599999999995,
"totalDebugInfoParseTime": 0.00033100000000000002,
"totalModuleCount": 9,
"totalModuleCountHasDebugInfo": 1,
"totalModuleCountWithIncompleteTypes": 0,
"totalModuleCountWithVariableErrors": 0,
"totalSymbolLocatorTime": {
"debuginfod": 6.5228070000000002
},
"totalSymbolTableIndexTime": 0.059214000000000003,
"totalSymbolTableParseTime": 0.205928,
"totalSymbolTableStripped": 0,
"totalSymbolTablesLoadedFromCache": 0,
"totalSymbolTablesSavedToCache": 0,
"transcript": [
{
"command": "symsrv",
"commandArguments": "",
"commandName": "symsrv",
"durationInSeconds": 0.00069099999999999999,
"error": "",
"output": "",
"timestampInEpochSeconds": 1744934015
},
{
"command": "settings set symbols.enable-external-lookup true",
"commandArguments": "symbols.enable-external-lookup true",
"commandName": "settings set",
"durationInSeconds": 4.1999999999999998e-05,
"error": "",
"output": "",
"timestampInEpochSeconds": 1744934015
},
{
"command": "settings insert-before plugin.symbol-locator.debuginfod.server-urls 0 https://our.intern.facebook.com/intern/debuginfod",
"commandArguments": "plugin.symbol-locator.debuginfod.server-urls 0 https://our.intern.facebook.com/intern/debuginfod",
"commandName": "settings insert-before",
"durationInSeconds": 5.5999999999999999e-05,
"error": "",
"output": "",
"timestampInEpochSeconds": 1744934015
},
{
"command": "target create --core \"/var/tmp/cores/c4crasher.crasher.1576894\"",
"commandArguments": "--core \"/var/tmp/cores/c4crasher.crasher.1576894\"",
"commandName": "target create",
"durationInSeconds": 6.7297630000000002,
"error": "",
"output": "Core file '/var/tmp/cores/c4crasher.crasher.1576894' (x86_64) was loaded.\n",
"timestampInEpochSeconds": 1744934017
},
{
"command": "fbpaste statistics dump",
"commandArguments": "statistics dump",
"commandName": "fbpaste",
"timestampInEpochSeconds": 1744934055
},
{
"command": "statistics dump",
"commandArguments": "",
"commandName": "statistics dump",
"timestampInEpochSeconds": 1744934055
}
]
}
```
Co-authored-by: George Hu <georgehuyubo@gmail.com>
|
|
This commit modifies the `DebuggerStats::ReportStatistics`
implementation to avoid loading symbol files for unloaded symbols. We
collect stats on debugger shutdown and without this change it can cause
the debugger to hang for a long while on shutdown if they symbols were
not previously loaded (e.g. `settings set target.preload-symbols
false`).
The implementation is done by adding an optional parameter to
`Module::GetSymtab` to control if the corresponding symbol file will be
loaded in the same way that can control it for `Module::GetSymbolFile`.
|
|
While looking at how to make Function::GetEndLineSourceInfo (which is
only used in "command source") work with discontinuous functions, I
realized there are other corner cases that this function doesn't handle.
The code assumed that the last line entry in the function will also
correspond to the last source line. This is probably true for
unoptimized code, but I don't think we can rely on the optimizer to
preserve this property. What's worse, the code didn't check that the
last line entry belonged to the same file as the first one, so if this
line entry was the result of inlining, we could end up using a line from
a completely different file.
To fix this, I change the algorithm to iterate over all line entries in
the function (which belong to the same file) and find the max line
number out of those. This way we can naturally handle the discontinuous
case as well.
This implementation is going to be slower than the previous one, but I
don't think that matters, because:
- this command is only used rarely, and interactively
- we have plenty of other code which iterates through the line table
I added some basic tests for the function operation. I don't claim the
tests to be comprehensive, or that the function handles all edge cases,
but test framework created here could be used for testing other
fixes/edge cases as well.
|
|
Function was merging equal data even if they weren't adjecant. This
caused a problem in command-disassemble.s test because the two ranges
describing the function would be merged and "swallow" the function
between them.
This PR copies/adapts the algorithm from
RangeVector::CombineConsecutiveEntries (which does not have the same
problem) and also adds a call to ComputeUpperBounds as moving entries
around invalidates the binary tree. (The lack of this call wasn't
noticed until now either because we were not calling methods which rely
on upper bounds (right now, it's only the ill-named FindEntryIndexes
method), or because we weren't merging anything.
|
|
(#126925)
We need to iterate through the all symbol context ranges returned by
(since #126505) SymbolContext::GetAddressRange. This also includes a fix
to print the function offsets as signed values.
I've also wanted to check that the addresses which are in the middle of
the function do *not* resolve to the function, but that's not entirely
the case right now. This appears to be a separate issue though, so I've
just left a TODO for now.
|
|
The command already supported disassembling multiple ranges, among other
reasons because inline functions can be discontinuous. The main thing
that was missing was being able to retrieve the function ranges from the
top level function object.
The output of the command for the case where the function entry point is
not its lowest address is somewhat confusing (we're showing negative
offsets), but it is correct.
|
|
Setting a breakpoint on `<symbol> + <offset>` used to work until
`2c76e88e9eb284d17cf409851fb01f1d583bb22a`, where this regex was
reworked. Now we only accept `<symbol>+ <offset>` or
`<symbol>+<offset>`.
This patch fixes the regression by adding yet another `[[:space:]]*`
component to the regex.
One could probably simplify the regex (or even replace the regex by just
calling the relevent `consumeXXX` APIs on `llvm::StringRef`). Though I
left that for the future.
rdar://130780342
|
|
Since the remote Shell test execution feature was added, these tests
should now be disabled on Windows target instead of Windows host.
It should fix failures on
https://lab.llvm.org/staging/#/builders/197/builds/76.
|
|
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.
|
|
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.
|
|
(#115539)
…293)"
This reverts commit da9499ebfb323602c42aeb674571fe89cec20ca6.
|
|
This patch introduces the amended feature flag for
[FEAT_SVE_AES](https://developer.arm.com/documentation/109697/2024_09/Feature-descriptions/The-Armv9-0-architecture-extension?lang=en#md457-the-armv90-architecture-extension__feat_FEAT_SVE_AES),
'**sve-aes**'. The existing flag associated with this feature,
'sve2-aes' must be retained as an alias of 'sve-aes' and 'sve2' for
backwards compatibility.
The
[ACLE](https://github.com/ARM-software/acle/blob/main/main/acle.md#aes-extension)
documents `__ARM_FEATURE_SVE2_AES`, which was previously defined to 1
when
> there is hardware support for the SVE2 AES (FEAT_SVE_AES) instructions
and if the associated ACLE intrinsics are available.
The front-end has been amended such that it is compatible with +sve2-aes
and +sve2+sve-aes.
|
|
This reverts commit eca3206d29e7ce97dd6336deaa3da96be37f8277.
This broke LLDB Linux bot for no apparent reason. I ll post a more
suitable fix later. Disabled command-expr-diagnostics.test on
windows for now.
|
|
This adds a minor change to command-expr-diagnostics.test to make
it pass on windows. Clang produces PDB on windows by default which
was ignoring main symbol due to optimization. The problem is fixed
by adding -gdwarf to commandline, making sure dwarf debug info gets
generated on both Windows and Linux.
|
|
Sometimes users (esp. gdb-longtime users) accidentally use GDB syntax,
such as `breakpoint foo`, and they would get an error message from LLDB
saying simply `Invalid command "breakpoint foo"`, which is not very
helpful.
This change provides additional suggestions to help correcting the
mistake.
|
|
This allows IDEs to render LLDB expression diagnostics to their liking
without relying on characterprecise ASCII art from LLDB. It is exposed
as a versioned SBStructuredData object, since it is expected that this
may need to be tweaked based on actual usage.
|
|
and implement them for dwim-print (a.k.a. `p`) as an example.
The next step will be to expose them as structured data in
SBCommandReturnObject.
|
|
This patch renames the `scripting template` subcommand to be `scripting
extension` instead since that would make more sense for upcoming
commands.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
|
|
|
|
Section IDs are 64 bit and if a section ID was over 4GB, then the
tabular output of the "target modules dump sections" command would not
align to the column headers. Also if the section type's name was too
long, the output wouldn't algin. This patch fixes this issue.
Old output looked like:
```
(lldb) image dump sections a.out
Sections for '/tmp/a.out' (arm):
SectID Type File Address Perm File Off. File Size Flags Section Name
---------- ---------------- --------------------------------------- ---- ---------- ---------- ---------- ----------------------------
0xffffffffffffffff container [0x0000000000001000-0x0000000000001010) rw- 0x00000074 0x00000010 0x00000000 a.out.PT_LOAD[0]
0x00000001 data [0x0000000000001000-0x0000000000001010) rw- 0x00000074 0x00000010 0x00000003 a.out.PT_LOAD[0]..data
0xfffffffffffffffe container [0x0000000000001000-0x0000000000001010) rw- 0x00000084 0x00000000 0x00000000 a.out.PT_TLS[0]
0x00000002 zero-fill [0x0000000000001000-0x0000000000001010) rw- 0x00000084 0x00000000 0x00000403 a.out.PT_TLS[0]..tbss
0x00000003 regular --- 0x00000084 0x00000001 0x00000000 a.out..strtab
0x00000004 regular --- 0x00000085 0x0000001f 0x00000000 a.out..shstrtab
```
New output looks like:
```
(lldb) image dump sections a.out
Sections for '/tmp/a.out' (arm):
SectID Type File Address Perm File Off. File Size Flags Section Name
------------------ ---------------------- --------------------------------------- ---- ---------- ---------- ---------- ----------------------------
0xffffffffffffffff container [0x0000000000001000-0x0000000000001010) rw- 0x00000074 0x00000010 0x00000000 a.out.PT_LOAD[0]
0x0000000000000001 data [0x0000000000001000-0x0000000000001010) rw- 0x00000074 0x00000010 0x00000003 a.out.PT_LOAD[0]..data
0xfffffffffffffffe container [0x0000000000001000-0x0000000000001010) rw- 0x00000084 0x00000000 0x00000000 a.out.PT_TLS[0]
0x0000000000000002 zero-fill [0x0000000000001000-0x0000000000001010) rw- 0x00000084 0x00000000 0x00000403 a.out.PT_TLS[0]..tbss
0x0000000000000003 regular --- 0x00000084 0x00000001 0x00000000 a.out..strtab
0x0000000000000004 regular --- 0x00000085 0x0000001f 0x00000000 a.out..shstrtab
```
|
|
Generate TargetParser extension information from tablegen. This includes FMV extension information. FMV only extensions are represented by a separate tablegen class.
Use MArchName/ArchKindEnumSpelling to avoid renamings.
Cases where there is simply a case difference are handled by
consistently uppercasing the AEK_ name in the emitted code.
Remove some Extensions which were not needed.
These had AEK entries but were never actually used for anything.
They are not present in Extensions[] data.
|
|
The help output for `thread backtrace` specifies that you can pass -1 to
`--count` to display all the frames.
```
-c <count> ( --count <count> )
How many frames to display (-1 for all)
```
However, that doesn't work:
```
(lldb) thread backtrace --count -1
error: invalid integer value for option 'c'
```
The problem is that we store the option value as an unsigned and the
code to parse the string correctly rejects it. There's two ways to fix
this:
1. Make `m_count` a signed value so that it accepts negative values and
appease the parser. The function that prints the frames takes an
unsigned so a negative value will just become a really large positive
value, which is what the current implementation relies on.
2. Keep `m_count` unsigned and instead use 0 the magic value to show all
frames. I don't really see a point in not showing any frames at all,
plus that's already broken (`error: error displaying backtrace for
thread: "0x0001"`).
This patch implements (2) and at the same time improve the error
reporting so that we print the invalid value when we cannot parse it.
rdar://123881767
|
|
I think it can work there but we need to correct the CHECK lines.
```
command-image-lookup-color.test:34:11: error: CHECK7: expected string not found in input
^
```
https://green.lab.llvm.org/green/view/LLDB/job/as-lldb-cmake/10880/testReport/
I don't have a way to see the full output.
|
|
On Linux `main.c` shows up in the symbol search but this is not the
case on Windows according to:
https://lab.llvm.org/buildbot/#/builders/219/builds/7422/steps/6/logs/stdio
It's possible we could make this test work there once function
search highlighting is implemented.
|
|
We can assume the correct symbol is found, so putting the line
number here is just going to confuse anyone extending these tests.
|
|
Fixes https://github.com/llvm/llvm-project/issues/57372
Previously some work has already been done on this. A PR was generated
but it remained in review:
https://reviews.llvm.org/D136462
In short previous approach was following:
Changing the symbol names (making the searched part colorized) ->
printing them -> restoring the symbol names back in their original form.
The reviewers suggested that instead of changing the symbol table, this
colorization should be done in the dump functions itself. Our strategy
involves passing the searched regex pattern to the existing dump
functions responsible for printing information about the searched
symbol. This pattern is propagated until it reaches the line in the dump
functions responsible for displaying symbol information on screen.
At this point, we've introduced a new function called
"PutCStringColorHighlighted," which takes the searched pattern, a prefix and suffix,
and the text and applies colorization to highlight the pattern in the
output. This approach aims to streamline the symbol search process to
improve readability of search results.
Co-authored-by: José L. Junior <josejunior@10xengineers.ai>
|
|
## Description
This pull request adds a new `stop-at-user-entry` option to LLDB
`process launch` command, allowing users to launch a process and pause
execution at the entry point of the program (for C-based languages,
`main` function).
## Motivation
This option provides a convenient way to begin debugging a program by
launching it and breaking at the desired entry point.
## Changes Made
- Added `stop-at-user-entry` option to `Options.td` and the
corresponding case in `CommandOptionsProcessLaunch.cpp` (short option is
'm')
- Implemented `GetUserEntryPointName` method in the Language plugins
available at the moment.
- Declared the `CreateBreakpointAtUserEntry` method in the Target API.
- Create Shell test for the command
`command-process-launch-user-entry.test`.
## Usage
`process launch --stop-at-user-entry` or `process launch -m` launches
the process and pauses execution at the entry point of the program.
|
