aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/Plugins/ObjectFile/JIT/ObjectFileJIT.cpp
AgeCommit message (Collapse)AuthorFilesLines
2023-03-31[lldb] Move ObjectFileJIT to lldbExpressionAlex Langford1-235/+0
In the spirit of not having lldbExpression rely on plugins, this move makes the most sense. ObjectFileJIT is not really a "plugin" in the sense that without it, expression evaluation doesn't work at all. This is different than something like ObjectFileELF where lldb can still technically debug non-ELF targets without it. For that reason, moving ObjectFileJIT into Expression where it will be used in conjunction with IRExecutionUnit makes the most sense. Differential Revision: https://reviews.llvm.org/D147084
2022-04-05[lldb] Change CreateMemoryInstance to take a WritableDataBufferJonas Devlieghere1-1/+1
Change the CreateMemoryInstance interface to take a WritableDataBuffer. Differential revision: https://reviews.llvm.org/D123073
2022-04-04[lldb] Prevent object file plugins from changing the data bufferJonas Devlieghere1-2/+2
The current design allows that the object file contents could be mapped by one object file plugin and then used by another. Presumably the idea here was to avoid mapping the same file twice. This becomes an issue when one object file plugin wants to map the file differently from the others. For example, ObjectFileELF needs to map its memory as writable while others likeObjectFileMachO needs it to be mapped read-only. This patch prevents plugins from changing the buffer by passing them is by value rather than by reference. Differential revision: https://reviews.llvm.org/D122944
2021-11-30[NFC] Refactor symbol table parsing.Greg Clayton1-17/+4
Symbol table parsing has evolved over the years and many plug-ins contained duplicate code in the ObjectFile::GetSymtab() that used to be pure virtual. With this change, the "Symbtab *ObjectFile::GetSymtab()" is no longer virtual and will end up calling a new "void ObjectFile::ParseSymtab(Symtab &symtab)" pure virtual function to actually do the parsing. This helps centralize the code for parsing the symbol table and allows the ObjectFile base class to do all of the common work, like taking the necessary locks and creating the symbol table object itself. Plug-ins now just need to parse when they are asked to parse as the ParseSymtab function will only get called once. This is a retry of the original patch https://reviews.llvm.org/D113965 which was reverted. There was a deadlock in the Manual DWARF indexing code during symbol preloading where the module was asked on the main thread to preload its symbols, and this would in turn cause the DWARF manual indexing to use a thread pool to index all of the compile units, and if there were relocations on the debug information sections, these threads could ask the ObjectFile to load section contents, which could cause a call to ObjectFileELF::RelocateSection() which would ask for the symbol table from the module and it would deadlock. We can't lock the module in ObjectFile::GetSymtab(), so the solution I am using is to use a llvm::once_flag to create the symbol table object once and then lock the Symtab object. Since all APIs on the symbol table use this lock, this will prevent anyone from using the symbol table before it is parsed and finalized and will avoid the deadlock I mentioned. ObjectFileELF::GetSymtab() was never locking the module lock before and would put off creating the symbol table until somewhere inside ObjectFileELF::GetSymtab(). Now we create it one time inside of the ObjectFile::GetSymtab() and immediately lock it which should be safe enough. This avoids the deadlocks and still provides safety. Differential Revision: https://reviews.llvm.org/D114288
2021-11-17Revert "[NFC] Refactor symbol table parsing."Greg Clayton1-4/+17
This reverts commit 951b107eedab1829f18049443f03339dbb0db165. Buildbots were failing, there is a deadlock in /Users/gclayton/Documents/src/llvm/clean/llvm-project/lldb/test/Shell/SymbolFile/DWARF/DW_AT_range-DW_FORM_sec_offset.s when ELF files try to relocate things.
2021-11-17[NFC] Refactor symbol table parsing.Greg Clayton1-17/+4
Symbol table parsing has evolved over the years and many plug-ins contained duplicate code in the ObjectFile::GetSymtab() that used to be pure virtual. With this change, the "Symbtab *ObjectFile::GetSymtab()" is no longer virtual and will end up calling a new "void ObjectFile::ParseSymtab(Symtab &symtab)" pure virtual function to actually do the parsing. This helps centralize the code for parsing the symbol table and allows the ObjectFile base class to do all of the common work, like taking the necessary locks and creating the symbol table object itself. Plug-ins now just need to parse when they are asked to parse as the ParseSymtab function will only get called once. Differential Revision: https://reviews.llvm.org/D113965
2021-10-25Add modules stats into the "statistics dump" command.Greg Clayton1-0/+1
The new module stats adds the ability to measure the time it takes to parse and index the symbol tables for each module, and reports modules statistics in the output of "statistics dump" along with the path, UUID and triple of the module. The time it takes to parse and index the symbol tables are also aggregated into new top level key/value pairs at the target level. Differential Revision: https://reviews.llvm.org/D112279
2021-10-21[lldb] Remove ConstString from GetPluginNameStatic of some pluginsPavel Labath1-9/+0
This patch deals with ObjectFile, ObjectContainer and OperatingSystem plugins. I'll convert the other types in separate patches. In order to enable piecemeal conversion, I am leaving some ConstStrings in the lowest PluginManager layers. I'll convert those as the last step. Differential Revision: https://reviews.llvm.org/D112061
2021-10-18[lldb] Return StringRef from PluginInterface::GetPluginNamePavel Labath1-5/+0
There is no reason why this function should be returning a ConstString. While modifying these files, I also fixed several instances where GetPluginName and GetPluginNameStatic were returning different strings. I am not changing the return type of GetPluginNameStatic in this patch, as that would necessitate additional changes, and this patch is big enough as it is. Differential Revision: https://reviews.llvm.org/D111877
2021-09-13[lldb] Remove PluginInterface::GetPluginVersionPavel Labath1-2/+0
In all these years, we haven't found a use for this function (it has zero callers). Lets just remove the boilerplate. Differential Revision: https://reviews.llvm.org/D109600
2021-07-02[lldb] Replace default bodies of special member functions with = default;Jonas Devlieghere1-1/+1
Replace default bodies of special member functions with = default; $ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix , https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html Differential revision: https://reviews.llvm.org/D104041
2020-06-24[lldb] Use std::make_unique<> (NFC)Jonas Devlieghere1-2/+2
Update the rest of lldb to use std::make_unique<>. I used clang-tidy to automate this, which probably missed cases that are wrapped in ifdefs.
2020-05-14[lldb] Switch Section-dumping code to raw_ostreamPavel Labath1-1/+2
Also, add a basic test for dumping sections.
2020-02-17[lldb/Plugins] Add missing initialize/terminate callsJonas Devlieghere1-0/+2
Add missing initialize and terminate calls for DynamicLoaderHexagonDYLD and ObjectFileJIT.
2020-02-17Revert "[lldb/CMake] Auto-generate the Initialize and Terminate calls for ↵Jonas Devlieghere1-2/+0
plugin" This is still failing spectacularly on the Windows bot and I still have no clue what's going on.
2020-02-17Re-land "[lldb/CMake] Auto-generate the Initialize and Terminate calls for ↵Jonas Devlieghere1-0/+2
plugin" This patch changes the way we initialize and terminate the plugins in the system initializer. It uses an approach similar to LLVM's TARGETS_TO_BUILD with a def file that enumerates the plugins. The previously landed patch got reverted because it was lacking: (1) A plugin definition for the Objective-C language runtime, (2) The dependency between the Static and WASM dynamic loader, (3) Explicit initialization of ScriptInterpreterNone for lldb-test. All issues have been addressed in this patch. Differential revision: https://reviews.llvm.org/D73067
2020-02-17Revert "[lldb/CMake] Auto-generate the Initialize and Terminate calls for ↵Jonas Devlieghere1-2/+0
plugin" This temporarily reverts commit 7d6da329dee1eda1761430d9097d1323f32c4c0c because it's causing test failures on the bots.
2020-02-17[lldb/CMake] Auto-generate the Initialize and Terminate calls for pluginJonas Devlieghere1-0/+2
This patch changes the way we initialize and terminate the plugins in the system initializer. It uses an approach similar to LLVM's TARGETS_TO_BUILD with a def file that enumerates the plugins. Differential revision: https://reviews.llvm.org/D73067
2020-01-24[lldb][NFC] Fix all formatting errors in .cpp file headersRaphael Isemann1-1/+1
Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp -------------------------------------------------===// ``` However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator `-*- C++ -*-` is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files). This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing `===//` (mostly caused by clang-format breaking the line). Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere Reviewed By: JDevlieghere Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73258
2019-07-31Add llvm-style RTTI to ObjectFile hierarchyPavel Labath1-0/+2
Summary: On the heels of D62934, this patch uses the same approach to introduce llvm RTTI support to the ObjectFile hierarchy. It also replaces the existing uses of GetPluginName doing run-time type checks with llvm::dyn_cast and friends. This formally introduces new dependencies from some other plugins to ObjectFile plugins. However, I believe this is fine because: - these dependencies were already kind of there, and the only reason we could get away with not modeling them explicitly was because the code was relying on magically knowing what will GetPluginName() return for a particular kind of object files. - the dependencies themselves are logical (it makes sense for SymbolVendorELF to depend on ObjectFileELF), or at least don't actively get in the way (the JitLoaderGDB->MachO thing). - they don't introduce any new dependency loops as ObjectFile plugins don't depend on any other plugins Reviewers: xiaobai, JDevlieghere, espindola Subscribers: emaste, mgorny, arichardson, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D65450 llvm-svn: 367413
2019-07-01Remove null checks of results of new expressionsPavel Labath1-8/+6
operator new doesn't return a null pointer, even if one turns off exceptions (it calls std::terminate instead). Therefore, all of this is dead code. llvm-svn: 364744
2019-05-23[lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine1-6/+6
Summary: NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]] This commit is the result of modernizing the LLDB codebase by using `nullptr` instread of `0` or `NULL`. See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html for more information. This is the command I ran and I to fix and format the code base: ``` run-clang-tidy.py \ -header-filter='.*' \ -checks='-*,modernize-use-nullptr' \ -fix ~/dev/llvm-project/lldb/.* \ -format \ -style LLVM \ -p ~/llvm-builds/debug-ninja-gcc ``` NOTE: There were also changes to `llvm/utils/unittest` but I did not include them because I felt that maybe this library shall be updated in isolation somehow. NOTE: I know this is a rather large commit but it is a nobrainer in most parts. Reviewers: martong, espindola, shafik, #lldb, JDevlieghere Reviewed By: JDevlieghere Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits Tags: #lldb, #llvm Differential Revision: https://reviews.llvm.org/D61847 llvm-svn: 361484
2019-04-10[NFC] Remove ASCII lines from commentsJonas Devlieghere1-2/+0
A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment. Its use is not really consistent across the code base, sometimes the lines are longer, sometimes they are shorter and sometimes they are omitted. Furthermore, it looks kind of weird with the 80 column limit, where the comment actually extends past the line, but not by much. Furthermore, when /// is used for Doxygen comments, it looks particularly odd. And when // is used, it incorrectly gives the impression that it's actually a Doxygen comment. I assume these lines were added to improve distinguishing between comments and code. However, given that todays editors and IDEs do a great job at highlighting comments, I think it's worth to drop this for the sake of consistency. The alternative is fixing all the inconsistencies, which would create a lot more churn. Differential revision: https://reviews.llvm.org/D60508 llvm-svn: 358135
2019-03-06Move RangeMap.h into UtilityPavel Labath1-1/+1
Summary: This file implements some general purpose data structures, and so it belongs to the Utility module. Reviewers: zturner, jingham, JDevlieghere, clayborg, espindola Subscribers: emaste, mgorny, javed.absar, arichardson, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D58970 llvm-svn: 355509
2019-02-13Replace 'ap' with 'up' suffix in variable names. (NFC)Jonas Devlieghere1-12/+12
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
2019-02-12Remove redundant ::get() for smart pointer. (NFC)Jonas Devlieghere1-3/+3
This commit removes redundant calls to smart pointer’s ::get() method. https://clang.llvm.org/extra/clang-tidy/checks/readability-redundant-smartptr-get.html llvm-svn: 353795
2019-02-11Simplify ObjectFile::GetUUIDPavel Labath1-2/+2
instead of returning the UUID through by-ref argument and a boolean value indicating success, we can just return it directly. Since the UUID class already has an invalid state, it can be used to denote the failure without the additional bool. llvm-svn: 353714
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
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
2019-01-03Simplify ObjectFile::GetArchitecturePavel Labath1-7/+5
Summary: instead of returning the architecture through by-ref argument and a boolean value indicating success, we can just return the ArchSpec directly. Since the ArchSpec already has an invalid state, it can be used to denote the failure without the additional bool. Reviewers: clayborg, zturner, espindola Subscribers: emaste, arichardson, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D56129 llvm-svn: 350291
2018-12-15Simplify Boolean expressionsJonas Devlieghere1-1/+1
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
2018-12-11Rename ObjectFile::GetHeaderAddress to GetBaseAddressPavel Labath1-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
2018-11-02Revert "[Symbol] Search symbols with name and type in a symbol file"Davide Italiano1-0/+1
It broke MacOS buildbots. llvm-svn: 346045
2018-11-02[Symbol] Search symbols with name and type in a symbol fileAleksandr Urakov1-1/+0
Summary: This patch adds possibility of searching a public symbol with name and type in a symbol file. It is helpful when working with PE, because PE's symtabs contain only imported / exported symbols only. Such a search is required for e.g. evaluation of an expression that calls some function of the debuggee. Reviewers: zturner, asmith, labath, clayborg, espindola Reviewed By: clayborg Subscribers: emaste, arichardson, aleksandr.urakov, jingham, lldb-commits, stella.stamenova Tags: #lldb Differential Revision: https://reviews.llvm.org/D53368 llvm-svn: 345957
2018-04-30Reflow paragraphs in comments.Adrian Prantl1-7/+6
This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2017-11-13Move ArchSpec to the Utility modulePavel Labath1-2/+1
The rationale here is that ArchSpec is used throughout the codebase, including in places which should not depend on the rest of the code in the Core module. This commit touches many files, but most of it is just renaming of #include lines. In a couple of cases, I removed the #include ArchSpec line altogether, as the file was not using it. In one or two places, this necessitated adding other #includes like lldb-private-defines.h. llvm-svn: 318048
2017-10-02Improve FreeBSD kernel debuggingEd Maste1-4/+4
FreeBSD kernel modules are actually relocatable (.o) ELF files and this previously caused some issues for LLDB. This change addresses these when using lldb to symbolicate FreeBSD kernel backtraces. The major problems: - Relocations were not being applied to the DWARF debug info despite there being code to do this. Several issues prevented it from working: - Relocations are computed at the same time as the symbol table, but in the case of split debug files, symbol table parsing always redirects to the primary object file, meaning that relocations would never be applied in the debug file. - There's actually no guarantee that the symbol table has been parsed yet when trying to parse debug information. - When actually applying relocations, it will segfault because the object files are not mapped with MAP_PRIVATE and PROT_WRITE. - LLDB returned invalid results when performing ordinary address-to- symbol resolution. It turned out that the addresses specified in the section headers were all 0, so LLDB believed all the sections had overlapping "file addresses" and would sometimes return a symbol from the wrong section. Patch by Brian Koropoff Differential Revision: https://reviews.llvm.org/D38142 llvm-svn: 314672
2017-06-29Move Timer and TraceOptions from Core to UtilityPavel Labath1-1/+1
Summary: The classes have no dependencies, and they are used both by lldb and lldb-server, so it makes sense for them to live in the lowest layers. Reviewers: zturner, jingham Subscribers: emaste, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D34746 llvm-svn: 306682
2017-03-22Move FileSpec from Host -> Utility.Zachary Turner1-1/+1
llvm-svn: 298536
2017-03-04Move DataBuffer / DataExtractor and friends from Core -> Utility.Zachary Turner1-3/+3
llvm-svn: 296943
2017-03-04Move UUID from Core -> Utility.Zachary Turner1-1/+1
llvm-svn: 296941
2017-03-03Move Log from Core -> Utility.Zachary Turner1-1/+1
All references to Host and Core have been removed, so this class can now safely be lowered into Utility. Differential Revision: https://reviews.llvm.org/D30559 llvm-svn: 296909
2017-02-02Move classes from Core -> Utility.Zachary Turner1-1/+1
This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
2016-09-06*** This commit represents a complete reformatting of the LLDB source codeKate Stone1-262/+167
*** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-05-19second pass over removal of Mutex and ConditionSaleem Abdulrasool1-1/+1
llvm-svn: 270024
2016-05-18remove use of Mutex in favour of std::{,recursive_}mutexSaleem Abdulrasool1-2/+2
This is a pretty straightforward first pass over removing a number of uses of Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there are interfaces which take Mutex::Locker & to lock internal locks. This patch cleans up most of the easy cases. The only non-trivial change is in CommandObjectTarget.cpp where a Mutex::Locker was split into two. llvm-svn: 269877
2015-03-18Move lldb-log.cpp to core/Logging.cppZachary Turner1-1/+0
So that we don't have to update every single #include in the entire codebase to #include this new header (which used to get included by lldb-private-log.h, we automatically #include "Logging.h" from within "Log.h". llvm-svn: 232653
2014-07-02Start converting usages of off_t to other types.Zachary Turner1-3/+4
off_t is a type which is used for file offsets. Even more specifically, it is only used by a limited number of C APIs that deal with files. Any usage of off_t where the variable is not intended to be used with one of these APIs is a bug, by definition. This patch corrects some easy mis-uses of off_t, generally by converting them to lldb::offset_t, but sometimes by using other types such as size_t, when appropriate. The use of off_t to represent these offsets has worked fine in practice on linux-y platforms, since we used _FILE_OFFSET_64 to guarantee that off_t was a uint64. On Windows, however, _FILE_OFFSET_64 is unrecognized, and off_t will always be 32-bit. So the usage of off_t on Windows actually leads to legitimate bugs. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D4358 llvm-svn: 212192
2014-04-21Remove useless declarationSylvestre Ledru1-2/+0
llvm-svn: 206764
2014-04-04sweep up -Wformat warnings from gccSaleem Abdulrasool1-4/+4
This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-02sanitise sign comparisonsSaleem Abdulrasool1-1/+1
This is a mechanical change addressing the various sign comparison warnings that are identified by both clang and gcc. This helps cleanup some of the warning spew that occurs during builds. llvm-svn: 205390