| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[lldb][test] Add test for completing ObjCObjectType (#95405) This is a minimal reproducer for a crash where we would try to call DumpTypeDescription on an incomplete type. This crash surfaced as part of an NFC refactor of some of the logic in GetCompleteQualType: (lldb) expr -l objc -- *(id)0x1234 Stack dump: 0. Program arguments: ./bin/lldb a.out -o "b main" -o run -o "expr -l objc -- *(id)0x1234" Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var LLVM_SYMBOLIZER_PATH to point to it): 0 lldb 0x0000000102ec768c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56 1 lldb 0x0000000102ec6010 llvm::sys::RunSignalHandlers() + 112 2 lldb 0x0000000102ec7fa8 SignalHandler(int) + 292 3 libsystem_platform.dylib 0x000000018c7a8c44 _sigtramp + 56 4 LLDB 0x0000000116b2030c lldb_private::TypeSystemClang::DumpTypeDescription(void*, lldb_private::Stream&, lldb::DescriptionLevel, lldb_private::ExecutionContextScope*) + 588 5 LLDB 0x00000001166b5124 lldb_private::CompilerType::DumpTypeDescription(lldb_private::Stream*, lldb::DescriptionLevel, lldb_private::ExecutionContextScope*) const + 228 6 LLDB 0x0000000116d4f08c IRForTarget::CreateResultVariable(llvm::Function&) + 2076 rdar://129633122 | 2 年前 | |
[lldb] Improve error message when evaluating expression when not stopped When trying to run an expression after a process has existed, you currently are shown the following error message: (lldb) p strlen("") error: Can't make a function caller while the process is running This error is wrong and pretty uninformative. After this patch, the following error message is shown: (lldb) p strlen("") error: unable to evaluate expression while the process is exited: the process must be stopped because the expression might require allocating memory. rdar://109731325 Differential revision: https://reviews.llvm.org/D151497 | 3 年前 | |
[lldb/lit] Introduce %clang_host substitutions Summary: This patch addresses an ambiguity in how our existing tests invoke the compiler. Roughly two thirds of our current "shell" tests invoke the compiler to build the executables for the host. However, there is also a significant number of tests which don't build a host binary (because they don't need to run it) and instead they hardcode a certain target. We also have code which adds a bunch of default arguments to the %clang substitutions. However, most of these arguments only really make sense for the host compilation. So far, this has worked mostly ok, because the arguments we were adding were not conflicting with the target-hardcoding tests (though they did provoke an occasional "argument unused" warning). However, this started to break down when we wanted to use target-hardcoding clang-cl tests (D69031) because clang-cl has a substantially different command line, and it was getting very confused by some of the arguments we were adding on non-windows hosts. This patch avoid this problem by creating separate %clang(xx,_cl)_host substutitions, which are specifically meant to be used for compiling host binaries. All funny host-specific options are moved there. To ensure that the regular %clang substitutions are not used for compiling host binaries (skipping the extra arguments) I employ a little hac^H^H^Htrick -- I add an invalid --target argument to the %clang substitution, which means that one has to use an explicit --target in order for the compilation to succeed. Reviewers: JDevlieghere, aprantl, mstorsjo, espindola Subscribers: emaste, arichardson, MaskRay, jfb, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D69619 | 6 年前 | |
[lldb] Return unimplemented error from ScriptedProcessInterface::CreatePluginObject After https://github.com/llvm/llvm-project/pull/68052 this function changed from returning a nullptr with return {}; to returning Expected and hitting llvm_unreachable before it could do so. I gather that we're never supposed to call this function, but on Windows we actually do call this function because interpreter->CreateScriptedProcessInterface() returns ScriptedProcessInterface not ScriptedProcessPythonInterface. Likely because target_sp->GetDebugger().GetScriptInterpreter() also does not return a Python related class. The previously XFAILed test crashed with: `` # .---command stderr------------ # | PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. # | Stack dump: # | 0. Program arguments: c:\\users\\tcwg\\david.spickett\\build-llvm\\bin\\lldb-test.exe ir-memory-map C:\\Users\\tcwg\\david.spickett\\build-llvm\\tools\\lldb\\test\\Shell\\Expr\\Output\\TestIRMemoryMapWindows.test.tmp C:\\Users\\tcwg\\david.spickett\\llvm-project\\lldb\\test\\Shell\\Expr/Inputs/ir-memory-map-basic # | 1. HandleCommand(command = "run") # | Exception Code: 0xC000001D # | #0 0x00007ff696b5f588 lldb_private::ScriptedProcessInterface::CreatePluginObject(class llvm::StringRef, class lldb_private::ExecutionContext &, class std::shared_ptr<class lldb_private::StructuredData::Dictionary>, class lldb_private::StructuredData::Generic *) C:\Users\tcwg\david.spickett\llvm-project\lldb\include\lldb\Interpreter\Interfaces\ScriptedProcessInterface.h:28:0 # | #1 0x00007ff696b1d808 llvm::Expected<std::shared_ptr<lldb_private::StructuredData::Generic> >::operator bool C:\Users\tcwg\david.spickett\llvm-project\llvm\include\llvm\Support\Error.h:567:0 # | #2 0x00007ff696b1d808 lldb_private::ScriptedProcess::ScriptedProcess(class std::shared_ptr<class lldb_private::Target>, class std::shared_ptr<class lldb_private::Listener>, class lldb_private::ScriptedMetadata const &, class lldb_private::Status &) C:\Users\tcwg\david.spickett\llvm-project\lldb\source\Plugins\Process\scripted\ScriptedProcess.cpp:115:0 # | #3 0x00007ff696b1d124 std::shared_ptr<lldb_private::ScriptedProcess>::shared_ptr C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\include\memory:1478:0 # | #4 0x00007ff696b1d124 lldb_private::ScriptedProcess::CreateInstance(class std::shared_ptr<class lldb_private::Target>, class std::shared_ptr<class lldb_private::Listener>, class lldb_private::FileSpec const *, bool) C:\Users\tcwg\david.spickett\llvm-project\lldb\source\Plugins\Process\scripted\ScriptedProcess.cpp:61:0 # | #5 0x00007ff69699c8f4 std::_Ptr_base<lldb_private::Process>::_Move_construct_from C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\include\memory:1237:0 # | #6 0x00007ff69699c8f4 std::shared_ptr<lldb_private::Process>::shared_ptr C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\include\memory:1534:0 # | #7 0x00007ff69699c8f4 std::shared_ptr<lldb_private::Process>::operator= C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\include\memory:1594:0 # | #8 0x00007ff69699c8f4 lldb_private::Process::FindPlugin(class std::shared_ptr<class lldb_private::Target>, class llvm::StringRef, class std::shared_ptr<class lldb_private::Listener>, class lldb_private::FileSpec const *, bool) C:\Users\tcwg\david.spickett\llvm-project\lldb\source\Target\Process.cpp:396:0 # | #9 0x00007ff6969bd708 std::_Ptr_base<lldb_private::Process>::_Move_construct_from C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\include\memory:1237:0 # | #10 0x00007ff6969bd708 std::shared_ptr<lldb_private::Process>::shared_ptr C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\include\memory:1534:0 # | #11 0x00007ff6969bd708 std::shared_ptr<lldb_private::Process>::operator= C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\include\memory:1594:0 # | #12 0x00007ff6969bd708 lldb_private::Target::CreateProcess(class std::shared_ptr<class lldb_private::Listener>, class llvm::StringRef, class lldb_private::FileSpec const *, bool) C:\Users\tcwg\david.spickett\llvm-project\lldb\source\Target\Target.cpp:215:0 # | #13 0x00007ff696b13af0 std::_Ptr_base<lldb_private::Process>::_Ptr_base C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\include\memory:1230:0 # | #14 0x00007ff696b13af0 std::shared_ptr<lldb_private::Process>::shared_ptr C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\include\memory:1524:0 # | #15 0x00007ff696b13af0 lldb_private::PlatformWindows::DebugProcess(class lldb_private::ProcessLaunchInfo &, class lldb_private::Debugger &, class lldb_private::Target &, class lldb_private::Status &) C:\Users\tcwg\david.spickett\llvm-project\lldb\source\Plugins\Platform\Windows\PlatformWindows.cpp:495:0 # | #16 0x00007ff6969cf590 std::_Ptr_base<lldb_private::Process>::_Move_construct_from C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\include\memory:1237:0 # | #17 0x00007ff6969cf590 std::shared_ptr<lldb_private::Process>::shared_ptr C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\include\memory:1534:0 # | #18 0x00007ff6969cf590 std::shared_ptr<lldb_private::Process>::operator= C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\include\memory:1594:0 # | #19 0x00007ff6969cf590 lldb_private::Target::Launch(class lldb_private::ProcessLaunchInfo &, class lldb_private::Stream *) C:\Users\tcwg\david.spickett\llvm-project\lldb\source\Target\Target.cpp:3274:0 # | #20 0x00007ff696fff82c CommandObjectProcessLaunch::DoExecute(class lldb_private::Args &, class lldb_private::CommandReturnObject &) C:\Users\tcwg\david.spickett\llvm-project\lldb\source\Commands\CommandObjectProcess.cpp:258:0 # | #21 0x00007ff696fab6c0 lldb_private::CommandObjectParsed::Execute(char const *, class lldb_private::CommandReturnObject &) C:\Users\tcwg\david.spickett\llvm-project\lldb\source\Interpreter\CommandObject.cpp:751:0 # ----------------------------- # error: command failed with exit status: 0xc000001d `` That might be a bug on the Windows side, or an artifact of how our build is setup, but whatever it is, having CreatePluginObject` return an error and the caller check it, fixes the failing test. The built lldb can run the script command to use Python, but I'm not sure if that means anything. | 2 年前 | |
Re-land "[test] Split LLDB tests into API, Shell & Unit" The original patch got reverted because it broke check-lldb on a clean build. This fixes that. llvm-svn: 374201 | 6 年前 | |
[lldb][test] Add test for completing ObjCObjectType (#95405) This is a minimal reproducer for a crash where we would try to call DumpTypeDescription on an incomplete type. This crash surfaced as part of an NFC refactor of some of the logic in GetCompleteQualType: (lldb) expr -l objc -- *(id)0x1234 Stack dump: 0. Program arguments: ./bin/lldb a.out -o "b main" -o run -o "expr -l objc -- *(id)0x1234" Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var LLVM_SYMBOLIZER_PATH to point to it): 0 lldb 0x0000000102ec768c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56 1 lldb 0x0000000102ec6010 llvm::sys::RunSignalHandlers() + 112 2 lldb 0x0000000102ec7fa8 SignalHandler(int) + 292 3 libsystem_platform.dylib 0x000000018c7a8c44 _sigtramp + 56 4 LLDB 0x0000000116b2030c lldb_private::TypeSystemClang::DumpTypeDescription(void*, lldb_private::Stream&, lldb::DescriptionLevel, lldb_private::ExecutionContextScope*) + 588 5 LLDB 0x00000001166b5124 lldb_private::CompilerType::DumpTypeDescription(lldb_private::Stream*, lldb::DescriptionLevel, lldb_private::ExecutionContextScope*) const + 228 6 LLDB 0x0000000116d4f08c IRForTarget::CreateResultVariable(llvm::Function&) + 2076 rdar://129633122 | 2 年前 | |
Reland "[lldb][ObjC] Don't query objective-c runtime for decls in C++ contexts" This relands https://github.com/llvm/llvm-project/pull/95963. It had to be reverted because the TestEarlyProcessLaunch.py test was failing on the incremental macOS bots. The test failed because it was relying on expression log output from the ObjC introspection routines (but was the expression was called from a C++ context). The relanded patch simply ensures that the test runs the expressions as ObjC expressions. When LLDB isn't able to find a clang::Decl in response to a FindExternalVisibleDeclsByName, it will fall-back to looking into the Objective-C runtime for that decl. This ends up doing a lot of work which isn't necessary when we're debugging a C++ program. This patch makes the ObjC lookup conditional on the language that the ExpressionParser deduced (which can be explicitly set using the expr --language option or is set implicitly if we're stopped in an ObjC frame or a C++ frame without debug-info). rdar://96236519 | 2 年前 | |
[lldb/test] Disable TestStringLiteralExpr.test on Windows This test, introduced by b042d15d2e39eea528c51a30fe637b9ea84250d3, fails on https://lab.llvm.org/buildbot/#/builders/83/builds/20933/steps/7/logs/stdio but succeeds on other targets, see for instance https://lab.llvm.org/buildbot/#/builders/68/builds/35462/steps/6/logs/stdio This test is not be arch specific, just disabling it on Windows. | 3 年前 | |
[lldb][test] Replace use of p with expression in Shell tests (NFC) In Shell tests, replace use of the p alias with the expression command. To avoid conflating tests of the alias with tests of the expression command, this patch canonicalizes to the use expression. See also D141539 which made the same change to API tests. Differential Revision: https://reviews.llvm.org/D146230 | 3 年前 | |
[lldb][gnustep] Add minimal GNUstepObjCRuntime plugin for LanguageTypeObjC on non-Apple platforms This is the next patch after D146058. We can now parse expressions to print instance variables from ObjC classes. Until now the expression parser would bail out with an error like this: error: expression failed to parse: error: Error [IRForTarget]: Couldn't find Objective-C indirect ivar symbol OBJC_IVAR_$_TestObj._int Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D146154 | 3 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 2 年前 | ||
| 3 年前 | ||
| 6 年前 | ||
| 2 年前 | ||
| 6 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 |