| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[ADT] Prepare to deprecate variadic StringSwitch::Cases. NFC. (#166020) Update all uses of variadic .Cases to use the initializer list overload instead. I plan to mark variadic .Cases as deprecated in a followup PR. For more context, see https://github.com/llvm/llvm-project/pull/163117. | 8 个月前 | |
[LLDB] Unify DWARF section name matching (#141344) Different object file formats support DWARF sections (COFF, ELF, MachO, PE/COFF, WASM). COFF and PE/COFF only matched a subset. This caused some GCC executables produced on MinGW to have issue later on when debugging. One example is that .debug_rnglists was not matched, which caused range-extraction to fail when printing a backtrace. This unifies the parsing of section names in ObjectFile::GetDWARFSectionTypeFromName, so all file formats can use the same naming convention. Since the prefixes are different, GetDWARFSectionTypeFromName only matches the suffixes (i.e. .debug_ needs to be stripped before). I added two tests to ensure the sections are correctly identified on Windows executables. | 1 年前 | |
[LLDB] Fix debuginfo ELF files overwriting Unified Section List (#166635) Recently I've been deep diving ELF cores in LLDB, aspiring to move LLDB closer to GDB in capability. One issue I encountered was a system lib losing it's unwind plan when loading the debuginfo. The reason for this was the debuginfo has the eh_frame section stripped and the main executable did not. The root cause of this was this line in [ObjectFileElf](https://github.com/llvm/llvm-project/blob/163933e9e7099f352ff8df1973f9a9c3d7def6c5/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp#L1972) // For eTypeDebugInfo files, the Symbol Vendor will take care of updating the // unified section list. if (GetType() != eTypeDebugInfo) unified_section_list = *m_sections_up; This would always be executed because CalculateType can never return an eTypeDebugInfo ObjectFile::Type ObjectFileELF::CalculateType() { switch (m_header.e_type) { case llvm::ELF::ET_NONE: // 0 - No file type return eTypeUnknown; case llvm::ELF::ET_REL: // 1 - Relocatable file return eTypeObjectFile; case llvm::ELF::ET_EXEC: // 2 - Executable file return eTypeExecutable; case llvm::ELF::ET_DYN: // 3 - Shared object file return eTypeSharedLibrary; case ET_CORE: // 4 - Core file return eTypeCoreFile; default: break; } return eTypeUnknown; } This makes sense as there isn't a explicit sh_type to denote that this file is a debuginfo. After some discussion with @clayborg and @GeorgeHuyubo we settled on joining the exciting unified section list with whatever new sections were being added. Adding each new unique section, or taking the section with the maximum file size. We picked this strategy to pick the section with the most information. In most scenarios, LHS should be SHT_NOBITS and RHS would be SHT_PROGBITS. Here is a diagram documenting the existing vs proposed new way. <img width="1666" height="1093" alt="image" src="https://github.com/user-attachments/assets/73ba9620-c737-439e-9934-ac350d88a3b5" /> | 8 个月前 | |
[lldb] Unwind through ARM Cortex-M exceptions automatically (#153922) When a processor faults/is interrupted/gets an exception, it will stop running code and jump to an exception catcher routine. Most processors will store the pc that was executing in a system register, and the catcher functions have special instructions to retrieve that & possibly other registers. It may then save those values to stack, and the author can add .cfi directives to tell lldb's unwinder where to find those saved values. ARM Cortex-M (microcontroller) processors have a simpler mechanism where a fixed set of registers are saved to the stack on an exception, and a unique value is put in the link register to indicate to the caller that this has taken place. No special handling needs to be written into the exception catcher, unless it wants to inspect these preserved values. And it is possible for a general stack walker to walk the stack with no special knowledge about what the catch function does. This patch adds an Architecture plugin method to allow an Architecture to override/augment the UnwindPlan that lldb would use for a stack frame, given the contents of the return address register. It resembles a feature where the LanguageRuntime can replace/augment the unwind plan for a function, but it is doing it at offset by one level. The LanguageRuntime is looking at the local register context and/or symbol name to decide if it will override the unwind rules. For the Cortex-M exception unwinds, we need to modify THIS frame's unwind plan if the CALLER's LR had a specific value. RegisterContextUnwind has to retrieve the caller's LR value before it has completely decided on the UnwindPlan it will use for THIS stack frame. This does mean that we will need one additional read of stack memory than we currently do when unwinding, on Armv7 Cortex-M targets. The unwinder walks the stack lazily, as stack frames are requested, and so now if you ask for 2 stack frames, we will read enough stack to walk 2 frames, plus we will read one extra word of memory, the spilled LR value from the stack. In practice, with 512-byte memory cache reads, this is unlikely to be a real performance hit. This PR includes a test with a yaml corefile description and a JSON ObjectFile, incorporating all of the necessary stack memory and symbol names from a real debug session I worked on. The architectural default unwind plans are used for all stack frames except the 0th because there's no instructions for the functions, and no unwind info. I may need to add an encoding of unwind fules to ObjectFileJSON in the future as we create more test cases like this. This PR depends on the yaml2macho-core utility from https://github.com/llvm/llvm-project/pull/153911 to run its API test. rdar://110663219 | 10 个月前 | |
[lldb] Add function to tell if a section is a GOT section (#165936) A global offset table is a section that holds the address of functions that are dynamically linked. The Swift plugin needs to know if sections are a global offset table or not. | 8 个月前 | |
[Minidump] Update Minidump file builder to continue when the Module's section cannot be found (#152009) Instead of returning an error when: - it can't obtain section information from a module. - there are other issues calculating the size. when we encounter such an error we log the error and continue with the other modules. tested with lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py --------- Co-authored-by: Bar Soloveychik <barsolo@fb.com> | 11 个月前 | |
[lldb/cmake] Implicitly pass arguments to llvm_add_library (#142583) If we're not touching them, we don't need to do anything special to pass them along -- with one important caveat: due to how cmake arguments work, the implicitly passed arguments need to be specified before arguments that we handle. This isn't particularly nice, but the alternative is enumerating all arguments that can be used by llvm_add_library and the macros it calls (it also relies on implicit passing of some arguments to llvm_process_sources). | 1 年前 | |
[ADT] Prepare to deprecate variadic StringSwitch::Cases. NFC. (#166020) Update all uses of variadic .Cases to use the initializer list overload instead. I plan to mark variadic .Cases as deprecated in a followup PR. For more context, see https://github.com/llvm/llvm-project/pull/163117. | 8 个月前 | |
[lldb/cmake] Implicitly pass arguments to llvm_add_library (#142583) If we're not touching them, we don't need to do anything special to pass them along -- with one important caveat: due to how cmake arguments work, the implicitly passed arguments need to be specified before arguments that we handle. This isn't particularly nice, but the alternative is enumerating all arguments that can be used by llvm_add_library and the macros it calls (it also relies on implicit passing of some arguments to llvm_process_sources). | 1 年前 | |
[lldb][AIX] Added XCOFF ParseSymtab handling (#141577) This PR is in reference to porting LLDB on AIX. Link to discussions on llvm discourse and github: 1. https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640 2. https://github.com/llvm/llvm-project/issues/101657 The complete changes for porting are present in this draft PR: https://github.com/llvm/llvm-project/pull/102601 **Description:** Adding ParseSymtab logic after creating sections. It is able to handle both 32 and 64 bit symbols, without the need to add template logic. This is an incremental PR on top of my previous couple of XCOFF support commits. | 1 年前 | |
[lldb] Corretly parse Wasm segments (#154727) My original implementation for parsing Wasm segments was wrong in two related ways. I had a bug in calculating the file vm address and I didn't fully understand the difference between active and passive segments and how that impacted their file vm address. With this PR, we now support parsing init expressions for active segments, rather than just skipping over them. This is necessary to determine where they get loaded. Similar to llvm-objdump, we currently only support simple opcodes (i.e. constants). We also currently do not support active segments that use a non-zero memory index. However this covers all segments for a non-trivial Swift binary compiled to Wasm. | 11 个月前 | |
| 1 年前 |