llvm-project/lldb/unittests/ObjectFile/CMakeLists.txt

add_subdirectory(Breakpad)
add_subdirectory(ELF)
add_subdirectory(MachO)
add_subdirectory(PECOFF)
Breakpad: Extract parsing code into a separate file Summary: This centralizes parsing of breakpad records, which was previously spread out over ObjectFileBreakpad and SymbolFileBreakpad. For each record type X there is a separate breakpad::XRecord class, and an associated parse function. The classes just store the information in the breakpad records in a more accessible form. It is up to the users to determine what to do with that data. This separation also made it possible to write some targeted tests for the parsing code, which was previously unaccessible, so I write a couple of those too. Reviewers: clayborg, lemo, zturner Reviewed By: clayborg Subscribers: mgorny, fedor.sergeev, lldb-commits Differential Revision: https://reviews.llvm.org/D56844 llvm-svn: 351541 2019-01-18 18:37:04 +08:00			`add_subdirectory(Breakpad)`
Open ELF core dumps with more than 64K sections Summary: Problem: There are three filelds in the ELF header - e_phnum, e_shnum, and e_shstrndx - that could be bigger than 64K and therefore do not fit in 16 bits reserved for them in the header. If this happens, pretty often there is a special section at index 0 which contains their real values for these fields in the section header in the fields sh_info, sh_size, and sh_link respectively. Fix: - Rename original fields in the header declaration. We want to have them around just in case. - Reintroduce these fields as 32-bit members at the end of the header. By default they are initialized from the header in Parse() method. - In Parse(), detect the situation when the header might have been extended into section info #0 and try to read it from the same data source. - ObjectFileELF::GetModuleSpecifications accesses some of these fields but the original parse uses too small data source. Re-parse the header if necessary using bigger data source. - ProcessElfCore::CreateInstance uses header with potentially sentinel values, but it does not access these fields, so a comment here is enough. Reviewers: labath Reviewed By: labath Subscribers: davidb, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D29095 Author: Eugene Birukov <eugenebi@hotmail.com> llvm-svn: 293714 2017-02-01 07:09:46 +08:00			`add_subdirectory(ELF)`
[lldb/ObjectFileMachO] Fetch shared cache images from our own shared cache Summary: On macOS 11, the libraries that have been integrated in the system shared cache are not present on the filesystem anymore. LLDB was using those files to get access to the symbols of those libraries. LLDB can get the images from the target process memory though. This has 2 consequences: - LLDB cannot load the images before the process starts, reporting an error if someone tries to break on a system symbol. - Loading the symbols by downloading the data from the inferior is super slow. It takes tens of seconds at the start of the debug session to populate the Module list. To fix this, we can use the library images LLDB has in its own mapping of the shared cache. Shared cache images are somewhat special as their LINKEDIT segment is moved to the end of the cache and thus the images are not contiguous in memory. All of this can hidden in ObjectFileMachO. This patch fixes a number of test failures on macOS 11 due to the first problem described above and adds some specific unittesting for the new SharedCache Host utilities. Reviewers: jasonmolenda, labath Subscribers: llvm-commits, lldb-commits Tags: #lldb, #llvm Differential Revision: https://reviews.llvm.org/D83023 2020-07-16 06:00:52 +08:00			`add_subdirectory(MachO)`
[Windows] Use information from the PE32 exceptions directory to construct unwind plans This patch adds an implementation of unwinding using PE EH info. It allows to get almost ideal call stacks on 64-bit Windows systems (except some epilogue cases, but I believe that they can be fixed with unwind plan disassembly augmentation in the future). To achieve the goal the CallFrameInfo abstraction was made. It is based on the DWARFCallFrameInfo class interface with a few changes to make it less DWARF-specific. To implement the new interface for PECOFF object files the class PECallFrameInfo was written. It uses the next helper classes: - UnwindCodesIterator helps to iterate through UnwindCode structures (and processes chained infos transparently); - EHProgramBuilder with the use of UnwindCodesIterator constructs EHProgram; - EHProgram is, by fact, a vector of EHInstructions. It creates an abstraction over the low-level unwind codes and simplifies work with them. It contains only the information that is relevant to unwinding in the unified form. Also the required unwind codes are read from the object file only once with it; - EHProgramRange allows to take a range of EHProgram and to build an unwind row for it. So, PECallFrameInfo builds the EHProgram with EHProgramBuilder, takes the ranges corresponding to every offset in prologue and builds the rows of the resulted unwind plan. The resulted plan covers the whole range of the function except the epilogue. Reviewers: jasonmolenda, asmith, amccarth, clayborg, JDevlieghere, stella.stamenova, labath, espindola Reviewed By: jasonmolenda Subscribers: leonid.mashinskiy, emaste, mgorny, aprantl, arichardson, MaskRay, lldb-commits, llvm-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67347 llvm-svn: 374528 2019-10-11 17:03:29 +08:00			`add_subdirectory(PECOFF)`