summaryrefslogtreecommitdiffstats
path: root/lldb/source/API
Commit message (Collapse)AuthorAgeFilesLines
* [API] Remove unneded LLDB_DISABLE_PYTHON markers.Davide Italiano2019-03-187-45/+0
| | | | llvm-svn: 356401
* Fix some "variable 'foo' set but not used" warningsPavel Labath2019-03-182-6/+2
| | | | | | gcc-8 diagnoses these. llvm-svn: 356378
* [Reproducers] Support capturing a reproducer without an explicit path.Jonas Devlieghere2019-03-121-0/+9
| | | | | | | | | | | | | | Tablegen doesn't support options that are both flags and take values as an argument. I noticed this when doing the tablegen rewrite, but forgot that that affected the reproducer --capture flag. This patch makes --capture a flag and adds --capture-path to specify a path for the reproducer. In reality I expect this to be mostly used for testing, but it could be useful nonetheless. Differential revision: https://reviews.llvm.org/D59238 llvm-svn: 355936
* [Reproducers] Implement log_append for function pointers.Jonas Devlieghere2019-03-113-10/+13
| | | | | | | | | | Changing the type in the DUMMY macro to void* doesn't actually fix the build error, because the argument type is deducted from the template (as opposed to when serializing through the instrumentation framework, where this would matter). Instead I've added a proper instance of log_append that takes function pointers and logs their address. llvm-svn: 355863
* [Reproducers] Replace callbacks with void*Jonas Devlieghere2019-03-113-13/+10
| | | | | | | | Callbacks in the LLDB_RECORD_DUMMY macros were causing build failures with the Xcode project. This patch replaces the function pointers with void pointers so they can be logged. llvm-svn: 355842
* Add "operator bool" to SB APIsPavel Labath2019-03-1156-0/+305
| | | | | | | | | | | | | | | | | | | | | | | Summary: Our python version of the SB API has (the python equivalent of) operator bool, but the C++ version doesn't. This is because our python operators are added by modify-python-lldb.py, which performs postprocessing on the swig-generated interface files. In this patch, I add the "operator bool" to all SB classes which have an IsValid method (which is the same logic used by modify-python-lldb.py). This way, we make the two interfaces more constent, and it allows us to rely on swig's automatic syntesis of python __nonzero__ methods instead of doing manual fixups. Reviewers: zturner, jingham, clayborg, jfb, serge-sans-paille Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D58792 llvm-svn: 355824
* [Reproducers] Add missing LLDB_RECORD_DUMMY macrosJonas Devlieghere2019-03-0811-7/+105
| | | | | | | Re-ran lldb-inst on the API folder to insert missing LLDB_RECORD_DUMMY macros. llvm-svn: 355711
* [Reproducers] Add LLDB_RECORD_DUMMYJonas Devlieghere2019-03-081-3/+6
| | | | | | | | | | | | | Add a macro that doesn't actually record anything but still toggles the API boundary. Removing just the register macros for lldb::thread_t wasn't sufficient on NetBSD because the serialization logic needed the underlying type to be complete. This macro should be used by functions that are currently unsupported, as they might trip the API boundary logic. This should be easy using the lldb-instr tool. llvm-svn: 355709
* [SBAPI] Log from record macroJonas Devlieghere2019-03-0738-3024/+75
| | | | | | | | | | | | | | | | The current record macros already log the function being called. This patch extends the macros to also log their input arguments and removes explicit logging from the SB API. This might degrade the amount of information in some cases (because of smarter casts or efforts to log return values). However I think this is outweighed by the increased coverage and consistency. Furthermore, using the reproducer infrastructure, diagnosing bugs in the API layer should become much easier compared to relying on log messages. Differential revision: https://reviews.llvm.org/D59101 llvm-svn: 355649
* [Reproducers] Disable registering lldb::thread_t everywhereJonas Devlieghere2019-03-071-11/+0
| | | | | | | | | As discussed on the mailing list, default serialization for thread ids is not correct, even if they're represented as basic types. I'm purposely leaving the corresponding record macros in place so that we don't break the API boundary detection. llvm-svn: 355610
* Repair the build when LLDB_DISABLE_PYTHON is setAlex Langford2019-03-071-20/+28
| | | | | | | | | | | Summary: If LLDB_DISABLE_PYTHON is set, some functions are unavailable but SBReproducer assumes they are. Let's conditionally register those functions since they are conditionally declared. Differential Revision: https://reviews.llvm.org/D59056 llvm-svn: 355575
* Pass /bigobj for SBReproducer.cpp with MSVCZachary Turner2019-03-061-0/+4
| | | | | | | | | /BIGOBJ is used to bypass certain COFF file format limitations and is used with, unsurprisingly, very big object files. This file has grown large enough that it needs this flag in order to compile successfully. llvm-svn: 355559
* Pass ConstString by value (NFC)Adrian Prantl2019-03-061-1/+1
| | | | | | | | | | | | | | | | | My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed. ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object. (This fixes rdar://problem/48640859 for the Apple folks) Differential Revision: https://reviews.llvm.org/D59030 llvm-svn: 355553
* [Reproducers] Guard register macros that take lldb::thread_t on WindowsJonas Devlieghere2019-03-061-0/+4
| | | | | | | | On Windows, lldb::thread_t is just a void*, so the we will try to allocate an object of type void when deserializing. Undef this for now until we support void* arguments. llvm-svn: 355519
* [Reproducers] Don't use VLA in SBReproducer redirectJonas Devlieghere2019-03-061-1/+1
| | | | | | This should unbreak the Windows bot. llvm-svn: 355518
* Re-commit logging for SBCompileUnit::GetNumLineEntries.Jason Molenda2019-03-061-1/+7
| | | | llvm-svn: 355473
* [Reproducers] Enable replay from SBRepro.Jonas Devlieghere2019-03-061-3/+0
| | | | | | | | | Now that the LLDB instrumentation macros are in place, we should use that to test reproducer replay. Differential revision: https://reviews.llvm.org/D58565 llvm-svn: 355470
* [Reproducers] Don't intercept SBDebugger::SetInputFileHandleJonas Devlieghere2019-03-061-3/+1
| | | | | | | With the reproducer logic in place for the command interpreter we no longer need to make SBDebugger::SetInputFileHandle a no-op. llvm-svn: 355469
* [Reproducers] Add SBReproducer macrosJonas Devlieghere2019-03-0666-983/+8842
| | | | | | | | | | This patch adds the SBReproducer macros needed to capture and reply the corresponding calls. This patch was generated by running the lldb-instr tool on the API source files. Differential revision: https://reviews.llvm.org/D57475 llvm-svn: 355459
* [SBAPI] Don't check IsValid in constructorJonas Devlieghere2019-03-0620-150/+136
| | | | | | | | | | | | | | | | | | | | | | | When running the test suite with the instrumentation macros, I noticed two lldb-mi tests regressed. The issue was the copy constructor of SBLineEntry. Without the macros the returned value would be elided, but with the macros the copy constructor was called. The latter using ::IsValid to determine whether the underlying opaque pointer should be set. This is likely a remnant of when ::IsValid would only check the validity of the smart pointer. In SBLineEntry however, it actually forwards to LineEntry::IsValid(). So what happened here was that because of the macros the copy constructor was called. The opaque pointer was valid but the LineEntry didn't consider itself valid. So the copied-to object ended up default initialized. This patch replaces all checks for IsValid in copy (assignment) constructors with checks for the opaque pointer itself. Differential revision: https://reviews.llvm.org/D58946 llvm-svn: 355458
* Revert logging addition to SBCompileUnit::GetNumLineEntries,Jason Molenda2019-03-051-6/+1
| | | | | | causing lldb-mi testsuite failures? llvm-svn: 355449
* Add logging to SBCompileUnit::GetNumLineEntries.Jason Molenda2019-03-051-1/+6
| | | | llvm-svn: 355435
* Move ProcessInfo from Host to Utility.Zachary Turner2019-03-043-1/+3
| | | | | | | | | | | | | | | | | | | | | There are set of classes in Target that describe the parameters of a process - e.g. it's PID, name, user id, and similar. However, since it is a bare description of a process and contains no actual functionality, there's nothing specifically that makes this appropriate for being in Target -- it could just as well be describing a process on the host, or some hypothetical virtual process that doesn't even exist. To cement this, I'm moving these classes to Utility. It's possible that we can find a better place for it in the future, but as it is neither Host specific nor Target specific, Utility seems like the most appropriate place for the time being. After this there is only 2 remaining references to Target from Host, which I'll address in a followup. Differential Revision: https://reviews.llvm.org/D58842 llvm-svn: 355342
* [build] Rename clang-headers to clang-resource-headersShoaib Meenai2019-03-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The current install-clang-headers target installs clang's resource directory headers. This is different from the install-llvm-headers target, which installs LLVM's API headers. We want to introduce the corresponding target to clang, and the natural name for that new target would be install-clang-headers. Rename the existing target to install-clang-resource-headers to free up the install-clang-headers name for the new target, following the discussion on cfe-dev [1]. I didn't find any bots on zorg referencing install-clang-headers. I'll send out another PSA to cfe-dev to accompany this rename. [1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits Tags: #clang, #sanitizers, #lldb, #openmp, #llvm Differential Revision: https://reviews.llvm.org/D58791 llvm-svn: 355340
* [Reproducers] Capture and replay interpreter commands.Jonas Devlieghere2019-03-021-2/+51
| | | | | | | | | | | | | | | | | This patch adds the necessary logic to capture and replay commands entered into the command interpreter. A DataRecorder shadows the input and writes its data to a know file. During replay this file is used as the command interpreter's input. It's possible to the command interpreter more than once, with a different input source. We support this scenario by using multiple buffers. The synchronization for this takes place at the SB layer, where we create a new recorder every time the debugger input is changed. During replay we use the corresponding buffer as input. Differential revision: https://reviews.llvm.org/D58564 llvm-svn: 355249
* [CMake] Make liblldb depend on clang-headersAlex Langford2019-02-281-0/+4
| | | | | | | | | | | Summary: The clang headers are useful when dealing with clang modules. There is also a way to get to the clang headers from the SB API so it would be nice if they were also available when we just build lldb. Differential Revision: https://reviews.llvm.org/D58793 llvm-svn: 355149
* [Reprodicuers] Check initializationJonas Devlieghere2019-02-281-0/+4
| | | | | | | If the reproducer is not initialzied, the call to ::Instance() will result in an assertion. llvm-svn: 355055
* [Reproducers] Initialize reproducers before initializing the debugger.Jonas Devlieghere2019-02-216-64/+35
| | | | | | | | | | | | | | | | As per the discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20190218/048007.html This commit implements option (3): > Go back to initializing the reproducer before the rest of the debugger. > The method wouldn't be instrumented and guarantee no other SB methods are > called or SB objects are constructed. The initialization then becomes part > of the replay. Differential revision: https://reviews.llvm.org/D58410 llvm-svn: 354631
* Replace 'ap' with 'up' suffix in variable names. (NFC)Jonas Devlieghere2019-02-1325-636/+636
| | | | | | | | | | | | | | | | | The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
* Use std::make_shared in LLDB (NFC)Jonas Devlieghere2019-02-1110-34/+54
| | | | | | | | | | | Unlike std::make_unique, which is only available since C++14, std::make_shared is available since C++11. Not only is std::make_shared a lot more readable compared to ::reset(new), it also performs a single heap allocation for the object and control block. Differential revision: https://reviews.llvm.org/D57990 llvm-svn: 353764
* Update files to the new header that were incorrectly landed with the oldChandler Carruth2019-02-112-8/+6
| | | | | | one. llvm-svn: 353663
* [Reproducers] SBReproducer framework: Capture & ReplayJonas Devlieghere2019-02-063-0/+124
| | | | | | | | | | | | | This is part two of the reproducer instrumentation framework. It contains the code to capture and replay function calls. The main user of this framework will be the SB API layer. For all the details refer to the RFC on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2019-January/014530.html Differential revision: https://reviews.llvm.org/D56322 llvm-svn: 353324
* [Expressions] Add support of expressions evaluation in some object's contextAleksandr Urakov2019-02-051-0/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds support of expression evaluation in a context of some object. Consider the following example: ``` struct S { int a = 11; int b = 12; }; int main() { S s; int a = 1; int b = 2; // We have stopped here return 0; } ``` This patch allows to do something like that: ``` lldb.frame.FindVariable("s").EvaluateExpression("a + b") ``` and the result will be `33` (not `3`) because fields `a` and `b` of `s` will be used (not locals `a` and `b`). This is achieved by replacing of `this` type and object for the expression. This has some limitations: an expression can be evaluated only for values located in the debuggee process memory (they must have an address of `eAddressTypeLoad` type). Reviewers: teemperor, clayborg, jingham, zturner, labath, davide, spyffe, serge-sans-paille Reviewed By: jingham Subscribers: abidh, lldb-commits, leonid.mashinskiy Tags: #lldb Differential Revision: https://reviews.llvm.org/D55318 llvm-svn: 353149
* Move FileAction, ProcessInfo and ProcessLaunchInfo from Target to HostPavel Labath2019-02-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: These classes describe the details of the process we are about to launch, and so they are naturally used by the launching code in the Host module. Previously they were present in Target because that is the most important (but by far not the only) user of the launching code. Since the launching code has other customers, must of which do not care about Targets, it makes sense to move these classes to the Host layer, next to the launching code. This move reduces the number of times that Target is included from host to 8 (it used to be 14). Reviewers: zturner, clayborg, jingham, davide, teemperor Subscribers: emaste, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D56602 llvm-svn: 353047
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1970-280/+210
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Replace auto -> llvm::Optional<uint64_t>Adrian Prantl2019-01-151-1/+2
| | | | | | This addresses post-commit feedback for https://reviews.llvm.org/D56688 llvm-svn: 351237
* Make CompilerType::getBitSize() / getByteSize() return an optional result. NFCAdrian Prantl2019-01-151-4/+4
| | | | | | | | | | | | | | | | | | | | | | | The code in LLDB assumes that CompilerType and friends use the size 0 as a sentinel value to signal an error. This works for C++, where no zero-sized type exists, but in many other programming languages (including I believe C) types of size zero are possible and even common. This is a particular pain point in swift-lldb, where extra code exists to double-check that a type is *really* of size zero and not an error at various locations. To remedy this situation, this patch starts by converting CompilerType::getBitSize() and getByteSize() to return an optional result. To avoid wasting space, I hand-rolled my own optional data type assuming that no type is larger than what fits into 63 bits. Follow-up patches would make similar changes to the ValueObject hierarchy. rdar://problem/47178964 Differential Revision: https://reviews.llvm.org/D56688 llvm-svn: 351214
* [SymbolFile] Remove SymbolContext parameter from FindTypes.Zachary Turner2019-01-142-4/+2
| | | | | | | | | | | | | | This parameter was only ever used with the Module set, and since a SymbolFile is tied to a module, the parameter turns out to be entirely unnecessary. Furthermore, it doesn't make a lot of sense to ask a caller to ask SymbolFile which is tied to Module X to find types for Module Y, but that possibility was open with the previous interface. By removing this parameter from the API, it makes it harder to use incorrectly as well as easier for an implementor to understand what it needs to do. llvm-svn: 351133
* Introduce SymbolFileBreakpad and use it to fill symtabPavel Labath2019-01-111-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit adds the glue code necessary to integrate the SymbolFileBreakpad into the plugin system. Most of the methods are stubbed out. The only method implemented method is AddSymbols, which parses the PUBLIC "section" of the breakpad "object file", and fills out the Module's symtab. To enable testing this, I've made two additional changes: - dump Symtab from the SymbolVendor class. The symtab was already being dumped as a part of the object file dump, but that happened before symbol vendor kicked in, so it did not reflect any symbols added there. - add ability to explicitly specify the external symbol file in lldb-test (so that the object file could be linked with the breakpad symbol file). To make things simpler, I've changed lldb-test from consuming multiple inputs (and dumping their symbols) to having it just process a single file per invocation. This was not a problem since everyone was using it that way already. Reviewers: clayborg, zturner, lemo, markmentovai, amccarth Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D56173 llvm-svn: 350924
* [CMake] Python bindings generation polishingStefan Granitz2019-01-041-7/+12
| | | | | | | | | | | | | | | | | Summary: Simplify SWIG invocation and handling of generated files. The `swig_wrapper` target can generate `LLDBWrapPython.cpp` and `lldb.py` in its own binary directory, so we can get rid of a few global variables and their logic. We can use the swig_wrapper's BINARY_DIR target property to refer to it and liblldb's LIBRARY_OUTPUT_DIRECTORY to refer to the framework/shared object output directory. Reviewers: JDevlieghere, aprantl, stella.stamenova, beanz, zturner, xiaobai Reviewed By: aprantl Subscribers: mgorny, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D55332 llvm-svn: 350393
* [CMake] Revised LLDB.framework buildsStefan Granitz2019-01-041-29/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add features to LLDB CMake builds that have so far only been available in Xcode. Clean up a few inconveniences and prepare further improvements. Options: * `LLDB_FRAMEWORK_BUILD_DIR` determines target directory (in build-tree) * `LLDB_FRAMEWORK_INSTALL_DIR` **only** determines target directory in install-tree * `LLVM_EXTERNALIZE_DEBUGINFO` allows externalized debug info (dSYM on Darwin, emitted to `bin`) * `LLDB_FRAMEWORK_TOOLS` determines which executables will be copied to the framework's Resources (dropped symlinking, removed INCLUDE_IN_SUITE, removed dummy targets) Other changes: * clean up `add_lldb_executable()` * include `LLDBFramework.cmake` from `source/API/CMakeLists.txt` * use `*.plist.in` files, which are typical for CMake and independent from Xcode * add clang headers to the framework bundle Reviewers: xiaobai, JDevlieghere, aprantl, davide, beanz, stella.stamenova, clayborg, labath Reviewed By: aprantl Subscribers: friss, mgorny, lldb-commits, #lldb Differential Revision: https://reviews.llvm.org/D55328 llvm-svn: 350391
* [lldb] Add a "display-recognized-arguments" target setting to show ↵Kuba Mracek2018-12-202-10/+19
| | | | | | | | recognized arguments by default Differential Revision: https://reviews.llvm.org/D55954 llvm-svn: 349856
* [API] Remove redundants get() from smart pointers. NFCJonas Devlieghere2018-12-2021-104/+97
| | | | | | | Removes redundant calls to ::get() from smart pointers in the source/API directory.. llvm-svn: 349821
* Replace MemoryRegionInfoSP with values and cleanup related codeTatyana Krasnukha2018-12-202-39/+39
| | | | | | Differential Revision: https://reviews.llvm.org/D55472 llvm-svn: 349766
* [lldb] Retrieve currently handled Obj-C exception via ↵Kuba Mracek2018-12-201-2/+1
| | | | | | | | | | | | __cxa_current_exception_type and add GetCurrentExceptionBacktrace SB ABI This builds on https://reviews.llvm.org/D43884 and https://reviews.llvm.org/D43886 and extends LLDB support of Obj-C exceptions to also look for a "current exception" for a thread in the C++ exception handling runtime metadata (via call to __cxa_current_exception_type). We also construct an actual historical SBThread/ThreadSP that contains frames from the backtrace in the Obj-C exception object. The high level goal this achieves is that when we're already crashed (because an unhandled exception occurred), we can still access the exception object and retrieve the backtrace from the throw point. In Obj-C, this is particularly useful because a catch+rethrow is very common and in those cases you currently don't have any access to the throw point backtrace. Differential Revision: https://reviews.llvm.org/D44072 llvm-svn: 349718
* Simplify Boolean expressionsJonas Devlieghere2018-12-1510-29/+26
| | | | | | | | | | | This patch simplifies boolean expressions acorss LLDB. It was generated using clang-tidy with the following command: run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD Differential revision: https://reviews.llvm.org/D55584 llvm-svn: 349215
* Move Broadcaster+Listener+Event combo from Core into UtilityPavel Labath2018-12-145-6/+6
| | | | | | | | | | | | | | | | | | Summary: These are general purpose "utility" classes, whose functionality is not debugger-specific in any way. As such, I believe they belong in the Utility module. This doesn't break any particular dependency (yet), but it reduces the number of Core dependencies across the board. Reviewers: zturner, jingham, teemperor, clayborg Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D55361 llvm-svn: 349157
* Add missing Initialize/Terminate for Architecture pluginsTatyana Krasnukha2018-12-131-0/+6
| | | | llvm-svn: 349036
* Rename ObjectFile::GetHeaderAddress to GetBaseAddressPavel Labath2018-12-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This function was named such because in the case of MachO files, the mach header is located at this address. However all (most?) usages of this function were not interested in that fact, but the fact that this address is used as the base address for expressing various relative addresses in the object file. For other object file formats, this name is not appropriate (and it's probably the reason why this function was not implemented in these classes). In the ELF case the ELF header will usually end up at this address, but this is a result of the linker optimizing the file layout and not a requirement of the spec. For COFF files, I believe the is no header located at this address either. Reviewers: clayborg, jasonmolenda, amccarth, lemo, stella.stamenova Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D55422 llvm-svn: 348849
* Re-commit "Introduce ObjectFileBreakpad"Pavel Labath2018-12-101-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This re-commits r348592, which was reverted due to a failing test on macos. The issue was that I was passing a null pointer for the "CreateMemoryInstance" callback when registering ObjectFileBreakpad, which caused crashes when attemping to load modules from memory. The correct thing to do is to pass a callback which always returns a null pointer (as breakpad files are never loaded in inferior memory). It turns out that there is only one test which exercises this code path, and it's mac-only, so I've create a new test which should run everywhere (except windows, as one cannot delete an executable which is being run). Unfortunately, this test still fails on linux for other reasons, but at least it gives us something to aim for. The original commit message was: This patch adds the scaffolding necessary for lldb to recognise symbol files generated by breakpad. These (textual) files contain just enough information to be able to produce a backtrace from a crash dump. This information includes: - UUID, architecture and name of the module - line tables - list of symbols - unwind information A minimal breakpad file could look like this: MODULE Linux x86_64 0000000024B5D199F0F766FFFFFF5DC30 a.out INFO CODE_ID 00000000B52499D1F0F766FFFFFF5DC3 FILE 0 /tmp/a.c FUNC 1010 10 0 _start 1010 4 4 0 1014 5 5 0 1019 5 6 0 101e 2 7 0 PUBLIC 1010 0 _start STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^ STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 + STACK CFI 1014 .cfa: $rbp 16 + Even though this data would normally be considered "symbol" information, in the current lldb infrastructure it is assumed every SymbolFile object is backed by an ObjectFile instance. So, in order to better interoperate with the rest of the code (particularly symbol vendors). In this patch I just parse the breakpad header, which is enough to populate the UUID and architecture fields of the ObjectFile interface. The rough plan for followup patches is to expose the individual parts of the breakpad file as ObjectFile "sections", which can then be used by other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary information. Reviewers: clayborg, zturner, lemo, amccarth Subscribers: mgorny, fedor.sergeev, markmentovai, lldb-commits Differential Revision: https://reviews.llvm.org/D55214 llvm-svn: 348773
OpenPOWER on IntegriCloud