| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
I noticed these were missing.
Differential Revision: https://reviews.llvm.org/D155653
|
|
Since 5d66f9fd8e97c05a5dba317d3ad2566e61ead1ff this test has
been upassing on Linaro's Windows on Arm lldb bot:
https://lab.llvm.org/buildbot/#/builders/219/builds/4320
I can't explain exactly how that happened, but I do see a bunch
of QEnvironment packets going by in that test. It is very likely
that the order would have been different on Windows.
Indeed, when it was xfailed back in df9051e7cfda5519f4584cda22e9ef2006517e94
the reason was not known either.
|
|
:: is now parsed as tok::coloncolon even in C mode.
|
|
Similar to ae316ac66ffff430997e342772fc4629c1acece0 for
QEMU_(UN)SET_ENV.
The iteration order of StringMap is not guaranteed to be deterministic.
Sort the entries to give deterministic packets for the tests added by
D108018.
|
|
This also ignores and deprecates the `-fdouble-square-bracket-attributes` command line flag, which seems to not be used anywhere. At least a code search exclusively found mentions of it in documentation: https://sourcegraph.com/search?q=context:global+-fdouble-square-bracket-attributes+-file:clang/*+-file:test/Sema/*+-file:test/Parser/*+-file:test/AST/*+-file:test/Preprocessor/*+-file:test/Misc/*+archived:yes&patternType=standard&sm=0&groupBy=repo
RFC: https://discourse.llvm.org/t/rfc-enable-c-11-c2x-attributes-in-all-standard-modes-as-an-extension-and-remove-fdouble-square-bracket-attributes
This enables `[[]]` attributes in all C and C++ language modes without warning by default. `-Wc++-extensions` does warn. GCC has enabled this extension in all C modes since GCC 10.
Reviewed By: aaron.ballman, MaskRay
Spies: #clang-vendors, beanz, JDevlieghere, Michael137, MaskRay, sstefan1, jplehr, cfe-commits, lldb-commits, dmgreen, jdoerfert, wenlei, wlei
Differential Revision: https://reviews.llvm.org/D151683
|
|
This patch adds the ability to pass native types from the script
interpreter to methods that use a {SB,}StructuredData argument.
To do so, this patch changes the `ScriptedObject` struture that holds
the pointer to the script object as well as the originating script
interpreter language. It also exposes that to the SB API via a new class
called `SBScriptObject`.
This structure allows the debugger to parse the script object and
convert it to a StructuredData object. If the type is not compatible
with the StructuredData types, we will store its pointer in a
`StructuredData::Generic` object.
This patch also adds some SWIG typemaps that checks the input argument to
ensure it's either an SBStructuredData object, in which case it just
passes it throught, or a python object that is NOT another SB type, to
provide some guardrails for the user.
rdar://111467140
Differential Revision: https://reviews.llvm.org/D155161
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
|
|
This rewrites DW_OP_addrx inside DWARFExpression as an DW_OP_addr so
that we can update addresses that are originally located in the
debug_addr section.
The full discussion behind this can be found in
https://discourse.llvm.org/t/dwarfexpression-and-dw-op-addrx/71627/12, but a
summary follows.
When SymbolFileDWARF::ParseVariableDIE creates DWARFExpressions for
variables whose location is an OP_addr, it knows how to remap
addresses appropriately in the DebugMap case. It then calls
DWARFExpression::Update_DW_OP_addr, which updates the value associated
with OP_addr.
However, when we have an OP_addrx, the update function does
nothing. This makes sense, as the DWARFExpression does not have a
mutable view of the debug_addr section. In non-DebugMap flows this is
not an issue, as the debug_addr contains the correct addresses of
variables. In DebugMap flows, this is problematic because the work
done by RelinkOSOAddress is lost. By updating the OP to OP_addr, we
can also update the address as required,
We also explored the alternative of relinking the debug_addr section
when we are initializing OSOs (InitOSO). However, this creates an
inconsistent story for users of
DWARFExpression::GetLocation_DW_OP_addr. This function returns an
address without telling callers whether that address came from an
OP_addr or an OP_addrx. If we preemptively relink OP_addrx results
without doing the same for OP_addr results, then callers can’t know
whether the address they got was an executable address or an object
file address. In other words, they can’t know whether they need to
call LinkOSOFileAddress on those results or not.
This patch addresses the majority of test failures when enabling DWARF
5 for MachO (over 200 test failures).
Differential Revision: https://reviews.llvm.org/D155198
|
|
/data/llvm-project/lldb/source/Plugins/Process/Utility/RegisterInfos_x86_64_with_base_shared.cpp:319:1: error: non-void function does
not return a value in all control paths [-Werror,-Wreturn-type]
}
^
1 error generated.
|
|
No longer needed following refactoring in D115178.
|
|
Classes implemented in Swift can be exposed to ObjC. For those classes, the ObjC
metadata is incomplete. Specifically, the encoded types of the ivars are incomplete. As
one might expect, the Swift metadata _is_ complete. In such cases, the Swift runtime
should be consulted when determining the dynamic type of a value.
Differential Revision: https://reviews.llvm.org/D152837
|
|
Summary:
[lldb][x86_64] This patch adds fs_base/gs_base support for Linux x86_64.
Originally, I plan to split the diff into two parts, one to refactoring lldb_xxx_x86_64 => x86_64::lldb_xxx across code base and the other one for adding fs_base/gs_base, but it turns out to be a non-trivial effort to split and very error prone so I decided to keep a single diff to get feedback.
GDB supports fs_base/gs_base registers while LLDB does not. Since both linux coredump note section and ptrace
supports them it is a missing feature.
For context, this is a required feature to support getting pthread pointer on linux from both live and dump debugging.
See thread below for details:
https://discourse.llvm.org/t/how-to-get-pthread-pointer-from-lldb/70542/2?u=jeffreytan81
Implementation wise, we have initially tried `#ifdef` approach to reuse the code but it is introducing very tricky bugs and proves
hard to maintain. Instead the diff completely separates the registers between x86_64 and x86_64_with_base so that non-linux related
implementations can use x86_64 registers while linux uses x86_64_with_base.
Here are the list of changes done in the patch:
* Registers in lldb-x86-register-enums.h are separated into two: x86_64 and x86_64_with_base
* fs_base/gs_base are added into x86_64_with_base
* All linux files are change to use x86_64::lldb_xxx => x86_64_with_base::lldb_xxx
* Support linux elf-core:
* A new RegisterContextLinuxCore_x86_64 class is added for ThreadElfCore
* RegisterContextLinuxCore_x86_64 overrides and uses its own register set supports fs_base/gs_base
* RegisterInfos_x86_64_with_base/RegisterInfos_x86_64_with_base_shared ared added to provide g_contained_XXX/g_invalidate_XXX and RegInfo related code sharing.
* `RegisterContextPOSIX_x86 ::m_gpr_x86_64` seems to be unused so I removed it.
* `NativeRegisterContextDBReg_x86::GetDR()` is overridden in `NativeRegisterContextLinux_x86_64` to make watchpoint work.
Reviewers:clayborg,labath,jingham,jdoerfert,JDevlieghere,kusmour,GeorgeHuyubo
Subscribers:
Tasks:
Tags:
Differential Revision: https://reviews.llvm.org/D155256
|
|
Reading through the Watchpoint class, I found this method
that wasn't being used properly, and a couple of ivars that
weren't used at all. Cleanup.
Differential Revision: https://reviews.llvm.org/D155768
|
|
This ensures we we don't crash when parsing a type that references an
unsupported type.
|
|
Reland after fixing regression in lldb.
Differential Revision: https://reviews.llvm.org/D155539
|
|
Currently frame var --regex sometimes searches globals, sometimes it doesn't.
This happens because `StackFrame::GetVariableList` always returns the biggest
list it has, regardless of whether only globals were requested or not. In other
words, if a previous call to `GetVariableList` requested globals, all subsequent
calls will see them.
The implication here is that users of `StackFrame::GetVariableList` are expected
to filter the results of this function. This is what we do for a vanilla
`frame var` command. But it is not what we do when `--regex` is used. This
commit solves the issue by:
1. Making `--regex` imply `--globals`. This matches the behavior of `frame var
<some_name>`, which will also search the global scope.
2. Making the `--regex` search respect the command object options.
See the added test for an example of the oddities this patch addresses. Without
the patch, the test fails. However it could be made to pass by calling a plain
`frame var` before calling `frame var --regex A::`.
Differential Revision: https://reviews.llvm.org/D155334
|
|
repl expressions to allow users to more easily invoke lldb commands.
This adds a new flag and lldb runtime command to allow users to manage the behavior of the lldb-vscode evaluate repl request.
When evaluating a repl context this now has runtime managed flag for control how the repl behaviors with the follow values:
* `variable` - the existing behavior, with this mode requests are evaluted in the current frame context as variable expressions. To trigger a lldb command prefix an expression with ` and it will be evaluted as an lldb command.
* `command` - all expressions are evaluated as lldb commands.
* `auto` - An alternative mode that will attempt to determine if the expression is an lldb command or a variable expression. Based off the intepreted results the expression will be evaluted either as a command or an expression.
Additionally, I enabled completions and ensured they work with the new repl expression behavior to provide auto-completes.
This commit includes updates to the tests to verify the new behavior after the previous failures from submitting https://reviews.llvm.org/D154030.
Differential Revision: https://reviews.llvm.org/D155248
|
|
On a subsequent commit, I intend to update the expression and call the evaluate
function more times. This refactors enables reusing some of the existing code
for that.
Differential Revision: https://reviews.llvm.org/D155197
|
|
We will need this code in a subsequent commit.
Differential Revision: https://reviews.llvm.org/D155332
|
|
Either clang-cl has different assembly output or we're not mapping
source to assembly properly on Windows. We (Linaro) will find out which.
https://lab.llvm.org/buildbot/#/builders/219/builds/4195
|
|
Add it to lit.local.cfg so that it's actually run, and change it to
(properly) use the %clang_host substitution.
|
|
Differential Revision: https://reviews.llvm.org/D155030
|
|
It was implicitly assumning that "/" would have no files in it, only
directories. That's not true, for instance on macOS if you've navigated
to the root directory in the Finder...
Since we're assuming everything we check against is a directory, then we
need to filter the completion for that coming in.
|
|
"sme" is just one of many cpuinfo features for SME but it's the
only one we need for testing.
The rest are related to the use of certain instructions and
don't change the register state available.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D154823
|
|
This test runs to a breakpoint on thread 0. Thread 0 then starts
thread 2 and 3, which both have breakpoints in them.
In https://lab.llvm.org/buildbot/#/builders/96/builds/41674
I think that we managed to do the first check on thread 2 before
thread 3 had started. Therefore "thread continue 3" failed.
So wait for all three to startup before we check their status.
I considered putting a timeout on the while like the wait_for... methods,
but the test itself already has a global timeout. Plus, I'd rather
not be tuning a timeout per piece of hardware this runs on.
99% of the time we will already have 3 threads when the check is done.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D154705
|
|
ModuleList unexpectedly caches module beyond test.
Tear it down.
- https://green.lab.llvm.org/green/view/LLDB/job/as-lldb-cmake/2260/testReport/junit/lldb-unit/Target___TargetTests_LocateModuleCallbackTest/GetOrCreateModuleWithCachedModule/
- https://green.lab.llvm.org/green/view/LLDB/job/as-lldb-cmake/2260/testReport/junit/lldb-unit/Target___TargetTests_LocateModuleCallbackTest/GetOrCreateModuleWithCachedModuleAndSymbol/
Differential Revision: https://reviews.llvm.org/D155333
|
|
This uses some friend class trickery to avoid some unneeded temporary
std::string allocations.
Differential Revision: https://reviews.llvm.org/D155035
|
|
GetOrCreateModuleWithCachedModuleAndSymbol tests on arm64, because of test failures
|
|
D153735 added the tests but it is failing due to POSIX path vs Windows path.
https://lab.llvm.org/buildbot/#/builders/219/builds/4084
Fix it.
- MODULE_PLATFORM_PATH is POSIX path.
- Normalize self.input_dir, FileSpec and SymbolFileSpec fullpath.
Differential Revision: https://reviews.llvm.org/D155124
|
|
This reverts commit 668a3efd42e7fea19a0d331f73345f2ac13cdf4f.
Reverting because of build errors:
In file included from /Users/buildslave/jenkins/workspace/as-lldb-cmake/llvm-project/lldb/source/API/SBPlatform.cpp:19:
/Users/buildslave/jenkins/workspace/as-lldb-cmake/llvm-project/lldb/include/lldb/Target/Target.h:1035:18: warning: parameter 'merged' not found in the function declaration [-Wdocumentation]
|
|
This reverts commit df054499c35cdda02b196b2ca5c0a326abdc0a29.
Reverting because of build errors
In file included from /Users/buildslave/jenkins/workspace/as-lldb-cmake/llvm-project/lldb/source/API/SBPlatform.cpp:19:
/Users/buildslave/jenkins/workspace/as-lldb-cmake/llvm-project/lldb/include/lldb/Target/Target.h:1035:18: warning: parameter 'merged' not found in the function declaration [-Wdocumentation]
|
|
This reverts commit 7f1028e9df52b4e7246f189a24684b1ca8c9bfbe.
This is because test failures
lldb-unit.Target/_/TargetTests/LocateModuleCallbackTest.GetOrCreateModuleWithCachedModule
lldb-unit.Target/_/TargetTests/LocateModuleCallbackTest.GetOrCreateModuleWithCachedModuleAndBreakpadSymbol
|
|
This reverts commit fb087c17c82309404fe0ebf3505c186642a719f7.
This is because of test failures:
lldb-unit.Target/_/TargetTests/LocateModuleCallbackTest.GetOrCreateModuleWithCachedModule
lldb-unit.Target/_/TargetTests/LocateModuleCallbackTest.GetOrCreateModuleWithCachedModuleAndBreakpadSymbol
|
|
These trigger the following error:
error: moving a temporary object prevents copy elision [-Werror,-Wpessimizing-move]
|
|
Make sure TestCTF only run on Darwin when ctfconvert and llvm-objdump
are available.
|
|
Add support for compressed CTF data. The flags in the header can
indicate whether the CTF body is compressed with zlib deflate. This
patch supports inflating the data before parsing.
Differential revision: https://reviews.llvm.org/D155221
|
|
In preparation for removing the #include "llvm/ADT/StringExtras.h"
from the header to source file of llvm/Support/Error.h, first add in
all the missing includes that were previously included transitively
through this header.
This is fixing all files missed in b0abd4893fa1, 39d8e6e22cd1,
a11efd49266f, 5551657b310b, and 90bfe2df25e7.
Differential Revision: https://reviews.llvm.org/D155178
|
|
Add support for the Compact C Type Format (CTF) in LLDB. The format
describes the layout and sizes of C types. It is most commonly consumed
by dtrace.
We generate CTF for the XNU kernel and want to be able to use this in
LLDB to debug kernels for which we don't have dSYMs (anymore). CTF is a
much more limited debug format than DWARF which allows is to be an order
of magnitude smaller: a 1GB dSYM can be converted to a handful of
megabytes of CTF. For XNU, the goal is not to replace DWARF, but rather
to have CTF serve as a "better than nothing" debug info format when
DWARF is not available.
It's worth noting that the LLVM toolchain does not support emitting CTF.
XNU uses ctfconvert to generate CTF from DWARF which is used for
testing.
Differential revision: https://reviews.llvm.org/D154862
|
|
Teach LLDB about the ctf (Compact C Type Format) section.
Differential revision: https://reviews.llvm.org/D154668
|
|
This has an `lldb_private` type in its parameter, it should be in
`lldb-private-types.h`
Differential Revision: https://reviews.llvm.org/D155129
|
|
Differential Revision: https://reviews.llvm.org/D155137
|
|
This code was introduced in 2fc93eabf7e132abd51d0ea0ad599beb3fa44334.
In order to improve readability of ParseVariableDIE, we move this code into a
helper function. The issue this code attempted to address was fixed between
Clangs 9 and 11; as such, if we ever want to delete this code, it is a lot
easier to do so after the refactor.
Differential Revision: https://reviews.llvm.org/D155100
|
|
In preparation for removing the #include "llvm/ADT/StringExtras.h"
from the header to source file of llvm/Support/Error.h, first add in
all the missing includes that were previously included transitively
through this header.
This is fixing all files missed in b0abd4893fa1, 39d8e6e22cd1,
a11efd49266f, and 5551657b310b.
Differential Revision: https://reviews.llvm.org/D155018
|
|
D153734 forgot to call `Platform::SetHostPlatform` before
`Debugger::CreateInstance`. Copy similar code.
https://github.com/llvm/llvm-project/blob/5007c78ce0936824972ec6ba3cfa598192087ee1/lldb/unittests/Expression/DWARFExpressionTest.cpp#L371-L374
Differential Revision: https://reviews.llvm.org/D155135
|
|
When we attach to a process, we task_for_pid(), ptrace(), and then
we try to halt execution of the process and time out after thirty
seconds if we cannot interrupt it. At this point, we must assume
we have no control of the inferior process and the attach has failed.
The error message we return currently is "operation timed out"; this
change improves on that error message to make it more clear what is
going on. Thanks to Jim for pointing this out.
rdar://101152233
|
|
When debugserver is attaching to a process, it first task_for_pid()'s
and then ptrace(PT_ATTACHEXC)'s. When that ptrace() fails to complete,
we are in a semi-attached state that we need to give up from, and
our error reporting isn't ideal -- we can even claim that the process
is already being debugged (by ourselves).
Differential Revision: https://reviews.llvm.org/D155037
rdar://101152233
|
|
RFC https://discourse.llvm.org/t/rfc-python-callback-for-target-get-module/71580
Use SWIG for the locate module callback the same as other Python callbacks.
TestLocateModuleCallback.py verifies the functionalities.
Differential Revision: https://reviews.llvm.org/D153735
|
|
RFC https://discourse.llvm.org/t/rfc-python-callback-for-target-get-module/71580
Updated Target::GetOrCreateModule to call locate module callback if set.
- include/lldb/Target/Platform.h, source/Target/Platform.cpp
- Implemented SetLocateModuleCallback and GetLocateModuleCallback*
- include/lldb/Target/Target.h, source/Target/Target.cpp
- Implemented CallLocateModuleCallbackIfSet.
- unittests/Target/LocateModuleCallbackTest.cpp
- Added comprehensive GetOrCreateModule tests.
Differential Revision: https://reviews.llvm.org/D153734
|
|
RFC https://discourse.llvm.org/t/rfc-python-callback-for-target-get-module/71580
SBFileSpec and SBModuleSpec will be used for locate module callback as Python
function arguments. This diff allows these things.
- Can be instantiated from SBPlatform.
- Can be passed to/from Python.
- Can be accessed for object offset and size.
Differential Revision: https://reviews.llvm.org/D153733
|
|
"line 0" in a DWARF linetable means something that doesn't have associated
source. The code for mixed disassembly has a comment indicating that
"line 0" should be skipped, but the wrong value was returned. Fix the return
value and add a test to check that we don't incorrectly show source lines
from the beginning of the file.
Reviewed By: jasonmolenda
Differential Revision: https://reviews.llvm.org/D112931
|
|
evaluation repl expressions to allow users to more easily invoke lldb commands."
This reverts commit 16317f1ced77e1d8711188f2fcc6c86a783d9c56.
Reverting because of test failures:
******************** TEST 'lldb-api :: tools/lldb-vscode/console/TestVSCode_console.py' FAILED ********************
Script:
--
/usr/local/Frameworks/Python.framework/Versions/3.10/bin/python3.10 /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/test/API/dotest.py -u CXXFLAGS -u CFLAGS --codesign-identity lldb_codesign --env LLVM_LIBS_DIR=/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/./lib --env LLVM_INCLUDE_DIR=/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/include --env LLVM_TOOLS_DIR=/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/./bin --libcxx-include-dir /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/include/c++/v1 --libcxx-library-dir /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lib --arch x86_64 --build-dir /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lldb-test-build.noindex --lldb-module-cache-dir /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lldb-test-build.noindex/module-cache-lldb/lldb-api --clang-module-cache-dir /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lldb-test-build.noindex/module-cache-clang/lldb-api --executable /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/./bin/lldb --compiler /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/./bin/clang --dsymutil /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/./bin/dsymutil --llvm-tools-dir /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/./bin --lldb-libs-dir /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/./lib --build-dir /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lldb-test-build.noindex -t --env TERM=vt100 /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/test/API/tools/lldb-vscode/console -p TestVSCode_console.py
https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/57586/
|
