summaryrefslogtreecommitdiff
path: root/lldb/source/API/SBSection.cpp
AgeCommit message (Collapse)Author
2023-01-30Revert "Revert "[lldb] Make SBSection::GetSectionData call ↵Muhammad Omair Javaid
Section::GetSectionData."" This reverts commit e1bbe50f5a48e9b5407de9e5f4ab8197dedc85c5. Differential Revision: https://reviews.llvm.org/D142672
2023-01-30Revert "[lldb] Make SBSection::GetSectionData call Section::GetSectionData."Muhammad Omair Javaid
This reverts commit 805600c7d573cf88cf035d01a2ea9389fc24d435. LLDB windows buildbots were broken by the TestSectionAPI.py test. I dont have full context of the commit to fix it. Reverting it temporarily. https://lab.llvm.org/buildbot/#/builders/83/builds/28617 https://lab.llvm.org/buildbot/#/builders/219/builds/180 Differential Revision: https://reviews.llvm.org/D142672
2023-01-27[lldb] Make SBSection::GetSectionData call Section::GetSectionData.Jorge Gorbe Moya
`SBSection::GetSectionData` and `Section::GetSectionData` are implemented differently, and the `SBSection` method doesn't handle compressed sections correctly. Differential Revision: https://reviews.llvm.org/D142672
2022-07-12[lldb] add SBSection.alignment to python bindingsDavid M. Lary
This commit adds SBSection.GetAlignment(), and SBSection.alignment as a python property to lldb. Reviewed By: clayborg, JDevlieghere, labath Differential Revision: https://reviews.llvm.org/D128069
2022-07-12Revert "[lldb] add SBSection.alignment to python bindings"Pavel Labath
The patch didn't get proper attribution. Will recommit. This reverts commit 4135abca897d1b945193f767cbf42a200b55bbdc.
2022-07-12[lldb] add SBSection.alignment to python bindingsPavel Labath
This commit adds SBSection.GetAlignment(), and SBSection.alignment as a python property to lldb. Reviewed By: clayborg, JDevlieghere, labath Differential Revision: https://reviews.llvm.org/D128069
2022-01-20[lldb] Decouple instrumentation from the reproducersJonas Devlieghere
Remove the last remaining references to the reproducers from the instrumentation. This patch renames the relevant files and macros. Differential revision: https://reviews.llvm.org/D117712
2022-01-09[lldb] Remove LLDB_RECORD_RESULT macroJonas Devlieghere
2022-01-09[lldb] Remove reproducer instrumentationJonas Devlieghere
This patch removes most of the reproducer instrumentation. It keeps around the LLDB_RECORD_* macros for logging. See [1] for more details. [1] https://lists.llvm.org/pipermail/lldb-dev/2021-September/017045.html Differential revision: https://reviews.llvm.org/D116847
2022-01-02[API] Remove redundant member initialization (NFC)Kazu Hirata
Identified with readability-redundant-member-init.
2020-05-14[lldb] Switch Section-dumping code to raw_ostreamPavel Labath
Also, add a basic test for dumping sections.
2020-02-17[lldb] Replace empty ctor en dtor bodies with =default (NFC)Jonas Devlieghere
Use = default instead of empty constructor and destructor bodies in the API layer.
2020-01-24[lldb][NFC] Fix all formatting errors in .cpp file headersRaphael Isemann
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-05-23[lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine
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-03[Reproducers] Capture return values of functions returning by ptr/refJonas Devlieghere
For some reason I had convinced myself that functions returning by pointer or reference do not require recording their result. However, after further considering I don't see how that could work, at least not with the current implementation. Interestingly enough, the reproducer instrumentation already (mostly) accounts for this, though the lldb-instr tool did not. This patch adds the missing macros and updates the lldb-instr tool. Differential revision: https://reviews.llvm.org/D60178 llvm-svn: 357639
2019-03-19[lldb] [Reproducer] Move SBRegistry registration into declaring filesMichal Gorny
Move SBRegistry method registrations from SBReproducer.cpp into files declaring the individual APIs, in order to reduce the memory consumption during build and improve maintainability. The current humongous SBRegistry constructor exhausts all memory on a NetBSD system with 4G RAM + 4G swap, therefore making it impossible to build LLDB. Differential Revision: https://reviews.llvm.org/D59427 llvm-svn: 356481
2019-03-11Add "operator bool" to SB APIsPavel Labath
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
2019-03-07[SBAPI] Log from record macroJonas Devlieghere
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
2019-03-06[Reproducers] Add SBReproducer macrosJonas Devlieghere
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
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth
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
2018-11-12Re-land "Extract construction of DataBufferLLVM into FileSystem"Jonas Devlieghere
This fixes some UB in isLocal detected by the sanitized bot. llvm-svn: 346707
2018-11-12Revert "Extract construction of DataBufferLLVM into FileSystem"Davide Italiano
It broke the lldb sanitizer bots. llvm-svn: 346694
2018-11-10Extract construction of DataBufferLLVM into FileSystemJonas Devlieghere
This moves construction of data buffers into the FileSystem class. Like some of the previous refactorings we don't translate the path yet because the functionality hasn't been landed in LLVM yet. Differential revision: https://reviews.llvm.org/D54272 llvm-svn: 346598
2017-03-06Remove FileSpec::ReadFileContents.Zachary Turner
This functionality is subsumed by DataBufferLLVM, which is also more efficient since it will try to mmap. However, we don't yet support mmaping writable private sections, and in some cases we were using ReadFileContents and then modifying the buffer. To address that I've added a flag to the DataBufferLLVM methods that allow you to map privately, which disables the mmaping path entirely. Eventually we should teach DataBufferLLVM to use mmap with writable private, but that is orthogonal to this effort. Differential Revision: https://reviews.llvm.org/D30622 llvm-svn: 297095
2017-03-04Move DataBuffer / DataExtractor and friends from Core -> Utility.Zachary Turner
llvm-svn: 296943
2017-03-03Move Log from Core -> Utility.Zachary Turner
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 Turner
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-08LLDB: API for iPermission of object file's sectionsAbhishek Aggarwal
Summary: - Added an API to public interface that provides permissions (RWX) of individual sections of an object file - Earlier, there was no way to find out this information through SB APIs - A possible use case of this API is: when a user wants to know the sections that have executable machine instructions and want to write a tool on top of LLDB based on this information - Differential Revision: https://reviews.llvm.org/D24251 llvm-svn: 280924
2016-09-06*** This commit represents a complete reformatting of the LLDB source codeKate Stone
*** 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
2014-10-22Added functions to the C++ API, for the benefit of non-8-bit byte architectures.Matthew Gardiner
New functions to give client applications to tools to discover target byte sizes for addresses prior to ReadMemory. Also added GetPlatform and ReadMemory to the SBTarget class, since they seemed to be useful utilities to have. Each new API has had a test case added. http://reviews.llvm.org/D5867 llvm-svn: 220372
2013-06-13Added a SBSection::GetParent() to the API.Greg Clayton
llvm-svn: 183948
2013-02-06<rdar://problem/13159777> Greg Clayton
lldb was mmap'ing archive files once per .o file it loads, now it correctly shares the archive between modules. LLDB was also always mapping entire contents of universal mach-o files, now it maps just the slice that is required. Added a new logging channel for "lldb" called "mmap" to help track future regressions. Modified the ObjectFile and ObjectContainer plugin interfaces to take a data offset along with the file offset and size so we can implement the correct caching and efficient reading of parts of files without mmap'ing the entire file like we used to. The current implementation still keeps entire .a files mmaped (once) and entire slices from universal files mmaped to ensure that if a client builds their binaries during a debug session we don't lose our data and get corrupt object file info and debug info. llvm-svn: 174524
2012-11-29Resolve printf formatting warnings on Linux:Daniel Malea
- use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-08-29<rdar://problem/11757916>Greg Clayton
Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes: - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was. - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile() Cleaned up header includes a bit as well. llvm-svn: 162860
2012-06-27Added the ability to read the dSYM plist file with source remappings even ↵Greg Clayton
when DebugSymbols isn't used to find the dSYM. We now parse the plist as XML in the MacOSX symbol vendor. Added the ability to get a section load address given a target which is needed for a previous checking which saves crashlogs. llvm-svn: 159298
2012-02-24<rdar://problem/10103468>Greg Clayton
I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address objects in breakpoint locations that had lldb_private::Section pointers into modules that had been removed or replaced. This also let to grabbing stale modules from those sections. So I needed to thread harded the Address, Section and related objects. To do this I modified the ModuleChild class to now require a ModuleSP on initialization so that a weak reference can created. I also changed all places that were handing out "Section *" to have them hand out SectionSP. All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild so all of the find plug-in, static creation function and constructors now require ModuleSP references instead of Module *. Address objects now have weak references to their sections which can safely go stale when a module gets destructed. This checkin doesn't complete the "target symfile add" command, but it does get us a lot clioser to being able to do such things without a high risk of crashing or memory corruption. llvm-svn: 151336
2012-01-29Switching back to using std::tr1::shared_ptr. We originally switched awayGreg Clayton
due to RTTI worries since llvm and clang don't use RTTI, but I was able to switch back with no issues as far as I can tell. Once the RTTI issue wasn't an issue, we were looking for a way to properly track weak pointers to objects to solve some of the threading issues we have been running into which naturally led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared pointer from just a pointer, which is also easily solved using the std::tr1::enable_shared_from_this class. The main reason for this move back is so we can start properly having weak references to objects. Currently a lldb_private::Thread class has a refrence to its parent lldb_private::Process. This doesn't work well when we now hand out a SBThread object that contains a shared pointer to a lldb_private::Thread as this SBThread can be held onto by external clients and if they end up using one of these objects we can easily crash. So the next task is to start adopting std::tr1::weak_ptr where ever it makes sense which we can do with lldb_private::Debugger, lldb_private::Target, lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and many more objects now that they are no longer using intrusive ref counted pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive pointers). llvm-svn: 149207
2011-12-19Work in progress for:Johnny Chen
rdar://problem/10577182 Audit lldb API impl for places where we need to perform a NULL check Add NULL checks for SBModule and SBSection APIs. llvm-svn: 146899
2011-11-13<rdar://problem/10126482>Greg Clayton
Fixed an issues with the SBType and SBTypeMember classes: - Fixed SBType to be able to dump itself from python - Fixed SBType::GetNumberOfFields() to return the correct value for objective C interfaces - Fixed SBTypeMember to be able to dump itself from python - Fixed the SBTypeMember ability to get a field offset in bytes (the value being returned was wrong) - Added the SBTypeMember ability to get a field offset in bits Cleaned up a lot of the Stream usage in the SB API files. llvm-svn: 144493
2011-09-24Added the ability to get all section contents, or the sectionGreg Clayton
contents starting at an offset (2 separate methods). This helps the scripting interface stay more natural by allowing both from Python. Added the ability to dump data with address annotations when call SBData::GetDescription(). Hooked up the SBSection to the __repr__ so you can print section objects from within python. Improved the dumping of symbols from python. Fixed the .i interface references which were set to "Relative to this Group" which somehow included Jim's "lldb-clean" root directory in the path. The interfaces are now in a folder called "interfaces" withing the Xcode API subfolder. llvm-svn: 140451
2011-09-24Fixed build issues after recent checkin.Greg Clayton
Added the ability to get the name of the SBSection. llvm-svn: 140444
2011-09-24Added to the public API to allow symbolication:Greg Clayton
- New SBSection objects that are object file sections which can be accessed through the SBModule classes. You can get the number of sections, get a section at index, and find a section by name. - SBSections can contain subsections (first find "__TEXT" on darwin, then us the resulting SBSection to find "__text" sub section). - Set load addresses for a SBSection in the SBTarget interface - Set the load addresses of all SBSection in a SBModule in the SBTarget interface - Add a new module the an existing target in the SBTarget interface - Get a SBSection from a SBAddress object This should get us a lot closer to being able to symbolicate using LLDB through the public API. llvm-svn: 140437