summaryrefslogtreecommitdiff
path: root/lldb/unittests
Commit message (Collapse)AuthorAgeFilesLines
* [lldb] Fix lua build after 27b6a4e63afeAlex Langford2023-05-151-2/+4
| | | | | | | This applies the same trick for Lua that I did for python in 27b6a4e63afe. Differential Revision: https://reviews.llvm.org/D150624
* [lldb] Complete OptionValue cleanup (NFC)Jonas Devlieghere2023-05-141-7/+7
| | | | | Make the `Get.*Value` and `Set.*Value` function private and migrate the last remaining call sites to the new overloaded/templated functions.
* [lldb] Mark most SBAPI methods involving private types as protected or privateAlex Langford2023-05-104-117/+99
| | | | | | | | | | | | | | | | | | | | | Many SB classes have public constructors or methods involving types that are private. Some are more obvious (e.g. containing lldb_private in the name) than others (lldb::FooSP is usually std::shared_pointer<lldb_private::Foo>). This commit explicitly does not address FileSP, so I'm leaving that one alone for now. Some of these were for other SB classes to use and should have been made protected/private with a friend class entry added. Some of these were public for some of the swig python helpers to use. I put all of those functions into a class and made them static methods. The relevant SB classes mark that class as a friend so they can access those private/protected members. I've also removed an outdated SBStructuredData test (can you guess which constructor it was using?) and updated the other relevant tests. Differential Revision: https://reviews.llvm.org/D150157
* [lldb] Fix language label in ObjC Language unittestCaroline Tice2023-05-061-1/+1
| | | | | | The recently added ObjC Language unittest, InvalidMethondNameParsing, currently has CPlusPlusLanguage as its language label (see https://reviews.llvm.org/D149804). There is already a test with the same name and same language label in the C++ Language unittests, so this creates a name conflict. This patch corrects the language label on the ObjC test. Differential Revision: https://reviews.llvm.org/D150019
* [lldb] Move Core/FileSpecList -> Utility/FileSpecList (NFC)Jonas Devlieghere2023-05-041-1/+1
| | | | | There's no reason for FileSpecList to live in lldb/Core while FileSpec lives in lldb/Utility. Move FileSpecList next to FileSpec.
* [lldb][NFCI] Add unittests for ObjCLanguage::MethodNameAlex Langford2023-05-043-0/+121
| | | | | | | I have a patch to refactor this class and I'd like a unittest in place to make sure I don't break anything. Differential Revision: https://reviews.llvm.org/D149804
* Allow scripted thread plans to modify the thread stop description whenJim Ingham2023-05-031-0/+8
| | | | they are completed.
* [lldb] Make exe_ctx an optional argument in OptionValueProperties (NFC)Jonas Devlieghere2023-05-021-4/+5
| | | | | | The majority of call sites are nullptr as the execution context. Refactor OptionValueProperties to make the argument optional and simplify all the callers.
* [lldb] Remove unused will_modify argument (NFC)Jonas Devlieghere2023-05-021-1/+1
| | | | | | Various OptionValue related classes are passing around will_modify but the value is never used. This patch simplifies the interfaces by removing the redundant argument.
* [lldb] Change ObjectValueDictionary to use a StringMapAlex Langford2023-05-011-2/+2
| | | | | | | | | | | | | llvm has a structure for maps where the key's type is a string. Using that also means that the keys for OptionValueDictionary don't stick around forever in ConstString's StringPool (even after they are gone). The only thing we lose here is ordering: iterating over the map where the keys are ConstStrings guarantees that we iterate in alphabetical order. StringMap makes no guarantees about the ordering when you iterate over the entire map. Differential Revision: https://reviews.llvm.org/D149482
* Revert "Host: generalise `GetXcodeSDKPath`"Douglas Yung2023-05-011-2/+1
| | | | | | | | This reverts commit ade3c6a6a88ed3a9b06c076406f196da9d3cc1b9. This breaks the build with GCC and affects at least 2 build bots: https://lab.llvm.org/buildbot/#/builders/217/builds/20568 https://lab.llvm.org/buildbot/#/builders/243/builds/5576
* Host: generalise `GetXcodeSDKPath`Saleem Abdulrasool2023-04-281-1/+2
| | | | | | | | | | | | This generalises the GetXcodeSDKPath hook to a GetSDKRoot path which will be re-used for the Windows support to compute a language specific SDK path on the platform. Because there may be other options that we wish to use to compute the SDK path, sink the XcodeSDK parameter into a structure which can pass a disaggregated set of options. Furthermore, optionalise the parameter as Xcode is not available for all platforms. Differential Revision: https://reviews.llvm.org/D149397 Reviewed By: JDevlieghere
* [lldb] Change return type of FileSpec::GetFileNameExtensionAlex Langford2023-04-261-2/+2
| | | | | | | | | | These don't really need to be in ConstStrings. It's nice that comparing ConstStrings is fast (just a pointer comparison) but the cost of creating the ConstString usually already includes the cost of doing a StringRef comparison anyway, so this is just extra work and extra memory consumption for basically no benefit. Differential Revision: https://reviews.llvm.org/D149300
* [lldb] Improve breakpoint management for interactive scripted processMed Ismail Bennani2023-04-251-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch improves breakpoint management when doing interactive scripted process debugging. In other to know which process set a breakpoint, we need to do some book keeping on the multiplexer scripted process. When initializing the multiplexer, we will first copy breakpoints that are already set on the driving target. Everytime we launch or resume, we should copy breakpoints from the multiplexer to the driving process. When creating a breakpoint from a child process, it needs to be set both on the multiplexer and on the driving process. We also tag the created breakpoint with the name and pid of the originator process. This patch also implements all the requirement to achieve proper breakpoint management. That involves: - Adding python interator for breakpoints and watchpoints in SBTarget - Add a new `ScriptedProcess.create_breakpoint` python method Differential Revision: https://reviews.llvm.org/D148548 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
* Make diagnostics API safer to useAdrian Prantl2023-04-211-0/+3
| | | | | | | | | | | | I received a crash report in DiagnosticManager that was caused by a nullptr diagnostic having been added. The API allows passing in a null unique_ptr, but all the methods are written assuming that all pointers a dereferencable. This patch makes it impossible to add a null diagnostic. rdar://107633615 Differential Revision: https://reviews.llvm.org/D148823
* [lldb] Change setting descriptions to use StringRef instead of ConstStringAlex Langford2023-04-191-3/+2
| | | | | | | | | These probably do not need to be in the ConstString StringPool as they don't really need any of the advantages that ConstStrings offer. Lifetime for these things is always static and we never need to perform comparisons for setting descriptions. Differential Revision: https://reviews.llvm.org/D148679
* [lldb] Change parameter type of StructuredData::ParseJSONAlex Langford2023-04-172-3/+2
| | | | | | | | | | Instead of taking a `const std::string &` we can take an `llvm::StringRef`. The motivation for this change is that many of the callers of `ParseJSON` end up creating a temporary `std::string` from an existing `StringRef` or `const char *` in order to satisfy the API. There's no reason we need to do this. Differential Revision: https://reviews.llvm.org/D148579
* [lldb] Add support for MSP430 in LLDB.Ilya Kuklin2023-04-171-0/+6
| | | | | | | | | | Add MSP430 to the list of available targets, implement MSP430 ABI, add support for debugging targets with 16-bit address size. The update is intended for use with MSPDebug, a GDB server implementation for MSP430. Reviewed By: bulbazord, DavidSpickett Differential Revision: https://reviews.llvm.org/D146965
* Revert "[lldb] Add support for MSP430 in LLDB."Anton Korobeynikov2023-04-171-6/+0
| | | | | | This reverts commit 82c02b733c7736507a41a26bebd37d3f8e88bd4e. Apparently, the original patch was not rebased onto `main
* [lldb] Add support for MSP430 in LLDB.Anton Korobeynikov2023-04-171-0/+6
| | | | | | | | | | Add MSP430 to the list of available targets, implement MSP430 ABI, add support for debugging targets with 16-bit address size. The update is intended for use with MSPDebug, a GDB server implementation for MSP430. Reviewed By: bulbazord, DavidSpickett Differential Revision: https://reviews.llvm.org/D146965
* [LLDB] Fix broken Windows unittests buildMuhammad Omair Javaid2023-04-171-1/+2
| | | | | | | | | | | LLDB Windows tests were broken because SymbolFilePDBTests.cpp failed to compile after 6cdfa295743729178ff6f15a8dcd36f8f7d27c2c. This patch fixes the SymbolFilePDBTests.cpp. (Tested on Surface X Pro) https://lab.llvm.org/buildbot/#/builders/219 Differential Revision: https://reviews.llvm.org/D147436
* [lldb] Allow evaluating expressions in C++20 modeMichael Buch2023-04-141-5/+7
| | | | | | | | | | | | | | | | | This patch allows users to evaluate expressions using `expr -l c++20`. Currently DWARF keeps the CU's at `DW_AT_language` at `DW_LANG_C_plus_plus_14` even when compiling with `-std=c++20`. So even in "C++20 programs" expression evaluation will by default be performed in `C++11` mode for now. Enabling `C++14` has been previously attempted at https://reviews.llvm.org/D80308 There are some remaining issues around evaluating C++20 expressions. Mainly, lack of support for C++20 AST nodes in `clang::ASTImporter`. But these can be addressed in follow-up patches.
* [lldb][test] Fix -Wsign-compare in RegisterFlagsTest.cpp (NFC)Jie Fu2023-04-141-2/+2
| | | | | | | | | | | | | | | | | | /data/llvm-project/third-party/unittest/googletest/include/gtest/gtest.h:1526:11: error: comparison of integers of different signs: 'const unsigned long long' and 'const int' [-Werror,-Wsign-compare] if (lhs == rhs) { ~~~ ^ ~~~ /data/llvm-project/third-party/unittest/googletest/include/gtest/gtest.h:1553:12: note: in instantiation of function template specialization 'testing::internal::CmpHelperEQ<unsigned long long, int>' requested here return CmpHelperEQ(lhs_expression, rhs_expression, lhs, rhs); ^ /data/llvm-project/lldb/unittests/Target/RegisterFlagsTest.cpp:128:3: note: in instantiation of function template specialization 'testing::internal::EqHelper::Compare<unsigned long long, int, nullptr>' requested here ASSERT_EQ(0x12345678ULL, rf.ReverseFieldOrder(0x12345678)); ^ /data/llvm-project/third-party/unittest/googletest/include/gtest/gtest.h:2056:32: note: expanded from macro 'ASSERT_EQ' ^ /data/llvm-project/third-party/unittest/googletest/include/gtest/gtest.h:2040:54: note: expanded from macro 'GTEST_ASSERT_EQ' ASSERT_PRED_FORMAT2(::testing::internal::EqHelper::Compare, val1, val2) ^ 1 error generated.
* [lldb] Show register fields using bitfield struct typesDavid Spickett2023-04-131-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change uses the information from target.xml sent by the GDB stub to produce C types that we can use to print register fields. lldb-server *does not* produce this information yet. This will only work with GDB stubs that do. gdbserver or qemu are 2 I know of. Testing is added that uses a mocked lldb-server. ``` (lldb) register read cpsr x0 fpcr fpsr x1 cpsr = 0x60001000 = (N = 0, Z = 1, C = 1, V = 0, TCO = 0, DIT = 0, UAO = 0, PAN = 0, SS = 0, IL = 0, SSBS = 1, BTYPE = 0, D = 0, A = 0, I = 0, F = 0, nRW = 0, EL = 0, SP = 0) ``` Only "register read" will display fields, and only when we are not printing a register block. For example, cpsr is a 32 bit register. Using the target's scratch type system we construct a type: ``` struct __attribute__((__packed__)) cpsr { uint32_t N : 1; uint32_t Z : 1; ... uint32_t EL : 2; uint32_t SP : 1; }; ``` If this register had unallocated bits in it, those would have been filled in by RegisterFlags as anonymous fields. A new option "SetChildPrintingDecider" is added so we can disable printing those. Important things about this type: * It is packed so that sizeof(struct cpsr) == sizeof(the real register). (this will hold for all flags types we create) * Each field has the same storage type, which is the same as the type of the raw register value. This prevents fields being spilt over into more storage units, as is allowed by most ABIs. * Each bitfield size matches that of its register field. * The most significant field is first. The last point is required because the most significant bit (MSB) being on the left/top of a print out matches what you'd expect to see in an architecture manual. In addition, having lldb print a different field order on big/little endian hosts is not acceptable. As a consequence, if the target is little endian we have to reverse the order of the fields in the value. The value of each field remains the same. For example 0b01 doesn't become 0b10, it just shifts up or down. This is needed because clang's type system assumes that for a struct like the one above, the least significant bit (LSB) will be first for a little endian target. We need the MSB to be first. Finally, if lldb's host is a different endian to the target we have to byte swap the host endian value to match the endian of the target's typesystem. | Host Endian | Target Endian | Field Order Swap | Byte Order Swap | |-------------|---------------|------------------|-----------------| | Little | Little | Yes | No | | Big | Little | Yes | Yes | | Little | Big | No | Yes | | Big | Big | No | No | Testing was done as follows: * Little -> Little * LE AArch64 native debug. * Big -> Little * s390x lldb running under QEMU, connected to LE AArch64 target. * Little -> Big * LE AArch64 lldb connected to QEMU's GDB stub, which is running an s390x program. * Big -> Big * s390x lldb running under QEMU, connected to another QEMU's GDB stub, which is running an s390x program. As we are not allowed to link core code to plugins directly, I have added a new plugin RegisterTypeBuilder. There is one implementation of this, RegisterTypeBuilderClang, which uses TypeSystemClang to build the CompilerType from the register fields. Reviewed By: jasonmolenda Differential Revision: https://reviews.llvm.org/D145580
* [lldb] Add dummy field to RegisterInfo for register flags use laterDavid Spickett2023-04-131-0/+1
| | | | | | | | | | | | | | | | | | | This structure is supposed to be trivial, so we cannot simply do "= nullptr;" on the new member. Doing that means you are non trivial, regardless of whether you emulate the previously implied constructor somehow. The next option is to update every use of brace initialisation. Given that this is some hundreds of lines, this change just adds a dummy pointer that is set to nullptr. Subsequent changes will actually use that to point to register flags information. Note: This change is not clang-format-ted because it changes a bunch of areas that are not themselves formatted. It would just add noise. Reviewed By: jasonmolenda, JDevlieghere Differential Revision: https://reviews.llvm.org/D145568
* [lldb] Add RegisterFlags classDavid Spickett2023-04-132-0/+124
| | | | | | | | | | | | | | | | | | | | | | | This models the "flags" node from GDB's target XML: https://sourceware.org/gdb/onlinedocs/gdb/Target-Description-Format.html This node is used to describe the fields of registers like cpsr on AArch64. RegisterFlags is a class that contains a list of register fields. These fields will be extracted from the XML sent by the remote. We assume that there is at least one field, that the fields are sorted in descending order and do not overlap. That will be enforced by the XML processor (the GDB client code in our case). The fields may not cover the whole register. To account for this RegisterFields will add anonymous padding fields so that sizeof(all fields) == sizeof(register). This will save a lot of hasssle later. Reviewed By: jasonmolenda, JDevlieghere Differential Revision: https://reviews.llvm.org/D145566
* [lldb] Add unittests for a few FileSpec methodsAlex Langford2023-04-071-0/+56
| | | | | | | | | | | This adds tests for: - FileSpec::TestFileNameExtensions - FileSpec::TestFileNameStrippingExtension - FileSpec::IsSourceImplementationFile This additionally updates incorrect documentation. Differential Revision: https://reviews.llvm.org/D147801
* Revert "[lldb] Move UnixSignals creation into Platform plugins"Alex Langford2023-03-273-5/+2
| | | | | | This reverts commit ee232506b870ce5282cc4da5ca493d41d361feb3. As discussed in https://reviews.llvm.org/D146668 we'll find another way forward.
* [lldb] Move UnixSignals creation into Platform pluginsAlex Langford2023-03-203-2/+5
| | | | | | | | | | | | | | | The high level goal of this change is to remove lldbTarget's dependency on lldbPluginProcessUtility. The reason for this existing dependency is so that we can create the appropriate UnixSignals object based on an ArchSpec. Instead of using the ArchSpec, we can instead take advantage of the Platform associated with the current Target. This is accomplished by adding a new method to Platform, CreateUnixSignals, which will create the correct UnixSignals object for us. We then can use `Platform::GetUnixSignals` and rely on that to give us the correct signals as needed. Differential Revision: https://reviews.llvm.org/D146263
* [lldb] Implement CrashReason using UnixSignalsDavid Spickett2023-03-201-0/+48
| | | | | | | | | | | | | | | | | | | | | | | | | By adding signal codes to UnixSignals and adding a new function where you can get a string with optional address and bounds. Added signal codes to the Linux, FreeBSD and NetBSD signal sets. I've checked the numbers against the relevant sources. Each signal code has a code number, description and printing options. By default you just get the descripton, you can opt into adding either a fault address or bounds information. Bounds signals we'll use the description, unless we have the bounds values in which case we say whether it is an upper or lower bound issue. GetCrashReasonString remains in CrashReason because we need it to be compiled only for platforms with siginfo_t. Ideally it would move into NativeProcessProtocol, but that is also used by NativeRegisterContextWindows, where there would be no siginfo_t. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D146044
* [lldb] Make MemoryCache::Read more resilientAlex Langford2023-03-162-0/+230
| | | | | | | | | | | | | | | | MemoryCache::Read is not resilient to partial reads when reading memory chunks less than or equal in size to L2 cache lines. There have been attempts in the past to fix this but nothing really solved the root of the issue. I first created a test exercising MemoryCache's implementation and documenting how I believe MemoryCache::Read should behave. I then rewrote the implementation of MemoryCache::Read as needed to make sure that the different scenarios behaved correctly. rdar://105407095 Differential Revision: https://reviews.llvm.org/D145624
* Use *{Map,Set}::contains (NFC)Kazu Hirata2023-03-151-2/+2
|
* [lldb] Update PythonDataObjectsTests for new exception formattingJonas Devlieghere2023-03-151-4/+7
| | | | | | | | | | PythonDataObjectsTest.TestExceptions started failing because the output of the python traceback printers is now consistent between python and cpython [1]. Work around the issue by supporting both variants. Thanks to Ismail for identifying the root cause. [1] https://github.com/python/cpython/issues/85203
* [lldb] Fix -Wdangling-else warning in CommunicationTestJonas Devlieghere2023-03-081-2/+4
| | | | | Fixed warning: suggest explicit braces to avoid ambiguous ‘else’ [-Wdangling-else]
* [lldb] Introduce new SymbolFileJSON and ObjectFileJSONJonas Devlieghere2023-03-082-0/+193
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce a new object and symbol file format with the goal of mapping addresses to symbol names. I'd like to think of is as an extremely simple textual symtab. The file format consists of a triple, a UUID and a list of symbols. JSON is used for the encoding, but that's mostly an implementation detail. The goal of the format was to be simple and human readable. The new file format is motivated by two use cases: - Stripped binaries: when a binary is stripped, you lose the ability to do thing like setting symbolic breakpoints. You can keep the unstripped binary around, but if all you need is the stripped symbols then that's a lot of overhead. Instead, we could save the stripped symbols to a file and load them in the debugger when needed. I want to extend llvm-strip to have a mode where it emits this new file format. - Interactive crashlogs: with interactive crashlogs, if we don't have the binary or the dSYM for a particular module, we currently show an unnamed symbol for those frames. This is a regression compared to the textual format, that has these frames pre-symbolicated. Given that this information is available in the JSON crashlog, we need a way to tell LLDB about it. With the new symbol file format, we can easily synthesize a symbol file for each of those modules and load them to symbolicate those frames. Here's an example of the file format: { "triple": "arm64-apple-macosx13.0.0", "uuid": "36D0CCE7-8ED2-3CA3-96B0-48C1764DA908", "symbols": [ { "name": "main", "type": "code", "size": 32, "address": 4294983568 }, { "name": "foo", "type": "code", "size": 8, "address": 4294983560 } ] } Differential revision: https://reviews.llvm.org/D145180
* [lldb/Plugins] Add memory writing capabilities to Scripted ProcessMed Ismail Bennani2023-03-031-0/+5
| | | | | | | | | | | | | This patch adds memory writing capabilities to the Scripted Process plugin. This allows to user to get a target address and a memory buffer on the python scripted process implementation that the user can make processing on before performing the actual write. This will also be used to write trap instruction to a real process memory to set a breakpoint. Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
* [lldb/Plugins] Add Attach capabilities to ScriptedProcessMed Ismail Bennani2023-03-031-0/+18
| | | | | | | | | | | | | | | | | | | | | | | This patch adds process attach capabilities to the ScriptedProcess plugin. This doesn't really expects a PID or process name, since the process state is already script, however, this allows to create a scripted process without requiring to have an executuble in the target. In order to do so, this patch also turns the scripted process related getters and setters from the `ProcessLaunchInfo` and `ProcessAttachInfo` classes to a `ScriptedMetadata` instance and moves it in the `ProcessInfo` class, so it can be accessed interchangeably. This also adds the necessary SWIG wrappers to convert the internal `Process{Attach,Launch}InfoSP` into a `SB{Attach,Launch}Info` to pass it as argument the scripted process python implementation and convert it back to the internal representation. rdar://104577406 Differential Revision: https://reviews.llvm.org/D143104 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
* [Linux] Add kernel.yama.ptrace_scope note when ptrace fails to attach.Jordan Rupprecht2023-03-021-0/+16
| | | | | | | | | | | | A common reason for LLDB failing to attach to an already-running process on Linux is the Yama security module: https://www.kernel.org/doc/Documentation/security/Yama.txt. This patch adds an explaination and suggested fix when it detects that case happening. This was previously proposed in D106226, but hasn't been updated in a while. The last request was to put the check in a target-specific location, which is the approach this patch takes. I believe Yama only exists on Linux, so it's put in that package. This has no end-to-end test because I'm not sure how to set `ptrace_scope` in a test environment -- if there are suggestions on how to do that, I'd be happy to add it. (Also, setting it to `3` is comically irreversible). I tested this locally. Reviewed By: DavidSpickett, labath Differential Revision: https://reviews.llvm.org/D144904
* [LLDB] Enable 64 bit debug/type offsetAlexander Yermolovich2023-02-222-2/+22
| | | | | | | | | | | | | | | | This came out of from https://discourse.llvm.org/t/dwarf-dwp-4gb-limit/63902 With big binaries we can have .dwp files where .debug_info.dwo section can grow beyond 4GB. We would like to support this in LLVM and in LLDB. The plan is to enable manual parsing of cu/tu index in DWARF library (https://reviews.llvm.org/D137882), and then switch internal index data structure to 64 bit. For the second part is to enable 64bit offset support in LLDB with this patch. Reviewed By: labath Differential Revision: https://reviews.llvm.org/D138618
* Revert "[LLDB] Enable 64 bit debug/type offset"Alexander Yermolovich2023-02-162-22/+2
| | | | This reverts commit 2062e90aa531e8445e5dc0e16222c0f246af1bf4.
* [LLDB] Enable 64 bit debug/type offsetAlexander Yermolovich2023-02-162-2/+22
| | | | | | | | | | | | | | | | | | This came out of from https://discourse.llvm.org/t/dwarf-dwp-4gb-limit/63902 With big binaries we can have .dwp files where .debug_info.dwo section can grow beyond 4GB. We would like to support this in LLVM and in LLDB. The plan is to enable manual parsing of cu/tu index in DWARF library (https://reviews.llvm.org/D137882), and then switch internal index data structure to 64 bit. For the second part is to enable 64bit offset support in LLDB with this patch. Depends on D139955 Reviewed By: labath Differential Revision: https://reviews.llvm.org/D138618
* Revert "[LLDB] Enable 64 bit debug/type offset"Alexander Yermolovich2023-02-132-22/+2
| | | | This reverts commit f36fe009c0fc1d655bfc6168730bedfa1b36e622.
* [LLDB] Enable 64 bit debug/type offsetAlexander Yermolovich2023-02-132-2/+22
| | | | | | | | | | | | | | | | | | This came out of from https://discourse.llvm.org/t/dwarf-dwp-4gb-limit/63902 With big binaries we can have .dwp files where .debug_info.dwo section can grow beyond 4GB. We would like to support this in LLVM and in LLDB. The plan is to enable manual parsing of cu/tu index in DWARF library (https://reviews.llvm.org/D137882), and then switch internal index data structure to 64 bit. For the second part is to enable 64bit offset support in LLDB with this patch. Depends on D139955 Reviewed By: labath Differential Revision: https://reviews.llvm.org/D138618
* [NFC][TargetParser] Replace uses of llvm/Support/Host.hArchibald Elliott2023-02-101-1/+1
| | | | | | | The forwarding header is left in place because of its use in `polly/lib/External/isl/interface/extract_interface.cc`, but I have added a GCC warning about the fact it is deprecated, because it is used in `isl` from where it is included by Polly.
* [NFC][TargetParser] Remove llvm/ADT/Triple.hArchibald Elliott2023-02-071-1/+1
| | | | | | I also ran `git clang-format` to get the headers in the right order for the new location, which has changed the order of other headers in two files.
* [lldb] Fix typo in LoongArch unittestWeining Lu2023-02-071-1/+1
|
* Reland "[lldb] Add support for DW_AT_default_value in template params"Michael Buch2023-01-273-2/+375
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | **Summary** This patch makes LLDB understand the `DW_AT_default_value` on template argument DIEs. As a result, type summaries will no longer contain the defaulted template arguments, reducing noise substantially. E.g., Before: ``` (lldb) v nested (std::vector<std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator <char> > > > > >) nested = size=0 {} ``` After: ``` (lldb) v nested (std::vector<std::vector<std::basic_string<char> > >) nested = size=0 {} ``` See discussion in https://reviews.llvm.org/D140423 **Testing** * Adjust API tests * Added unit-test Differential Revision: https://reviews.llvm.org/D141828
* Revert "[lldb] Add support for DW_AT_default_value in template params"David Spickett2023-01-273-377/+2
| | | | | | | | | This reverts commit 1cf52e540242f968e0cf789587bcf76c01332aeb. Due to test failures on Arm and AArch64 bots: https://lab.llvm.org/buildbot/#/builders/96/builds/34718 (which were obscured by an earlier build failure)
* [lldb][Test][NFC] TestCreateClassTemplateDecl: make variable names more readableMichael Buch2023-01-271-32/+33
| | | | Suggested in https://reviews.llvm.org/D140030
* [lldb] Add support for DW_AT_default_value in template paramsMichael Buch2023-01-273-2/+377
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | **Summary** This patch makes LLDB understand the `DW_AT_default_value` on template argument DIEs. As a result, type summaries will no longer contain the defaulted template arguments, reducing noise substantially. E.g., Before: ``` (lldb) v nested (std::vector<std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator <char> > > > > >) nested = size=0 {} ``` After: ``` (lldb) v nested (std::vector<std::vector<std::basic_string<char> > >) nested = size=0 {} ``` See discussion in https://reviews.llvm.org/D140423 **Testing** * Adjust API tests * Added unit-test Differential Revision: https://reviews.llvm.org/D141828
View Lorry Controller Status