summaryrefslogtreecommitdiffstats
path: root/lldb/source/API/SBSymbol.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine2019-05-231-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Reproducers] Capture return values of functions returning by ptr/refJonas Devlieghere2019-04-031-1/+1
| | | | | | | | | | | | | | | 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
* [lldb] [Reproducer] Move SBRegistry registration into declaring filesMichal Gorny2019-03-191-0/+34
| | | | | | | | | | | | 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
* Add "operator bool" to SB APIsPavel Labath2019-03-111-0/+4
| | | | | | | | | | | | | | | | | | | | | | | 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
* [SBAPI] Log from record macroJonas Devlieghere2019-03-071-14/+0
| | | | | | | | | | | | | | | | 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] Add SBReproducer macrosJonas Devlieghere2019-03-061-8/+52
| | | | | | | | | | 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
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-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
* Move Log from Core -> Utility.Zachary Turner2017-03-031-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
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-181/+115
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* second pass over removal of Mutex and ConditionSaleem Abdulrasool2016-05-191-2/+3
| | | | llvm-svn: 270024
* Make many mangled functions that might demangle a name be allowed to specify ↵Greg Clayton2015-07-081-2/+2
| | | | | | a language to use in order to soon support Pascal and Java demangling. Dawn Perchik will take care of making this so. llvm-svn: 241751
* Add a GetDisplayName() API to SBFrame, SBFunction and SBSymbolEnrico Granata2015-07-061-0/+14
| | | | | | | | | | This API is currently a no-op (in the sense that it has the same behavior as the already existing GetName()), but is meant long-term to provide a best-for-visualization version of the name of a function It is still not hooked up to the command line 'bt' command, nor to the 'gui' mode, but I do have ideas on how to make that work going forward rdar://21203242 llvm-svn: 241482
* Resubmitting 240466 after fixing the linux test suite failures.Greg Clayton2015-06-251-4/+5
| | | | | | | | | | | | | | | A few extras were fixed - Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected. - Since some places want to access the address as a reference, I added a few new functions to symbol: Address &Symbol::GetAddressRef(); const Address &Symbol::GetAddressRef() const; Linux test suite passes just fine now. <rdar://problem/21494354> llvm-svn: 240702
* sweep up -Wformat warnings from gccSaleem Abdulrasool2014-04-041-2/+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
* Disassembler::DisassembleRange() currently calls Target::ReadMemoryJason Molenda2013-09-121-1/+3
| | | | | | | | | | | | | with prefer_file_cache == false. This is what we want to do when the user is doing a disassemble command -- show the actual memory contents in case the memory has been corrupted or something -- but when we're profiling functions for stepping or unwinding (ThreadPlanStepRange::GetInstructionsForAddress, UnwindAssemblyInstEmulation::GetNonCallSiteUnwindP) we can read __TEXT instructions directly out of the file, if it exists. <rdar://problem/14397491> llvm-svn: 190638
* <rdar://problem/13521159>Greg Clayton2013-03-271-2/+2
| | | | | | | | LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
* Convert from the C-based LLVM Disassembler shim to the full MC Disassembler ↵Jim Ingham2013-03-021-2/+7
| | | | | | | | | | | | API's. Calculate "can branch" using the MC API's rather than our hand-rolled regex'es. As extra credit, allow setting the disassembly flavor for x86 based architectures to intel or att. <rdar://problem/11319574> <rdar://problem/9329275> llvm-svn: 176392
* Don't expose the pthread_mutex_t underlying the Mutex & Mutex::Locker classes. Jim Ingham2012-05-041-1/+1
| | | | | | | | | | | | | No one was using it and Locker(pthread_mutex_t *) immediately asserts for pthread_mutex_t's that don't come from a Mutex anyway. Rather than try to make that work, we should maintain the Mutex abstraction and not pass around the platform implementation... Make Mutex::Locker::Lock take a Mutex & or a Mutex *, and remove the constructor taking a pthread_mutex_t *. You no longer need to call Mutex::GetMutex to pass your mutex to a Locker (you can't in fact, since I made it private.) llvm-svn: 156221
* No functionality changes, mostly cleanup.Greg Clayton2012-04-111-1/+1
| | | | | | | | Cleaned up the Mutex::Locker and the ReadWriteLock classes a bit. Also cleaned up the GDBRemoteCommunication class to not have so many packet functions. Used the "NoLock" versions of send/receive packet functions when possible for a bit of performance. llvm-svn: 154458
* Export the ability to see if a symbol is externally visible and also if the ↵Greg Clayton2012-04-021-0/+17
| | | | | | symbol was synthetically added to the symbol table (the symbol was not part of the symbol table itself but came from another section). llvm-svn: 153893
* <rdar://problem/10997402>Greg Clayton2012-03-071-20/+11
| | | | | | | | | | | This fix really needed to happen as a previous fix I had submitted for calculating symbol sizes made many symbols appear to have zero size since the function that was calculating the symbol size was calling another function that would cause the calculation to happen again. This resulted in some symbols having zero size when they shouldn't. This could then cause infinite stack traces and many other side affects. llvm-svn: 152244
* <rdar://problem/10103468>Greg Clayton2012-02-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* SBFrame is now threadsafe using some extra tricks. One issue is that stackGreg Clayton2012-01-301-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
* Switching back to using std::tr1::shared_ptr. We originally switched awayGreg Clayton2012-01-291-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* <rdar://problem/10126482>Greg Clayton2011-11-131-3/+4
| | | | | | | | | | | | | | | 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
* Added some functions to our API related to classifying symbols as code, data,Greg Clayton2011-03-311-0/+8
| | | | | | | | | | | | const data, etc, and also for SBAddress objects to classify their type of section they are in and also getting the module for a section offset address. lldb::SymbolType SBSymbol::GetType(); lldb::SectionType SBAddress::GetSectionType (); lldb::SBModule SBAddress::GetModule (); llvm-svn: 128602
* Cleaned up the Disassembler code a bit more. You can now request a disassemblerGreg Clayton2011-03-251-0/+1
| | | | | | | | | | | | | plugin by name on the command line for when there is more than one disassembler plugin. Taught the Opcode class to dump itself so that "disassembler -b" will dump the bytes correctly for each opcode type. Modified all places that were passing the opcode bytes buffer in so that the bytes could be displayed to just pass in a bool that indicates if we should dump the opcode bytes since the opcode now lives inside llvm_private::Instruction. llvm-svn: 128290
* Export the ability to get the start and end addresses for functionsGreg Clayton2011-03-021-0/+44
| | | | | | | | | | | | | | | | | | | | | | | | and symbols, and also allow clients to get the prologue size in bytes: SBAddress SBFunction::GetStartAddress (); SBAddress SBFunction::GetEndAddress (); uint32_t SBFunction::GetPrologueByteSize (); SBAddress SBSymbol::GetStartAddress (); SBAddress SBSymbol::GetEndAddress (); uint32_t SBSymbol::GetPrologueByteSize (); llvm-svn: 126892
* The LLDB API (lldb::SB*) is now thread safe!Greg Clayton2010-12-201-0/+4
| | | | llvm-svn: 122262
* Fixed SBFrame to properly check to make sure it has a valid m_opaque_sp objectGreg Clayton2010-12-141-0/+6
| | | | | | before trying to use it. llvm-svn: 121748
* Added symbol table access through the module for now. We might need to exposeGreg Clayton2010-12-071-1/+6
| | | | | | a SBSymtab class, but for now, we expose the symbols through the module. llvm-svn: 121112
* Modified all logging calls to hand out shared pointers to make sure weGreg Clayton2010-11-061-2/+2
| | | | | | | | | | | don't crash if we disable logging when some code already has a copy of the logger. Prior to this fix, logs were handed out as pointers and if they were held onto while a log got disabled, then it could cause a crash. Now all logs are handed out as shared pointers so this problem shouldn't happen anymore. We are also using our new shared pointers that put the shared pointer count and the object into the same allocation for a tad better performance. llvm-svn: 118319
* Added copy constructors and assignment operators to all lldb::SB* classesGreg Clayton2010-11-051-0/+13
| | | | | | so we don't end up with weak exports with some compilers. llvm-svn: 118312
* Improved API logging.Greg Clayton2010-10-301-27/+12
| | | | llvm-svn: 117772
* Clean up the API logging code:Caroline Tice2010-10-261-11/+15
| | | | | | | | | | | | | | - Try to reduce logging to one line per function call instead of tw - Put all arguments & their values into log for calls - Add 'this' parameter information to function call logging, making it show the appropriate internal pointer (this.obj, this.sp, this.ap...) - Clean up some return values - Remove logging of constructors that construct empty objects - Change '==>' to '=>' for showing result values... - Fix various minor bugs - Add some protected 'get' functions to help getting the internal pointers for the 'this' arguments... llvm-svn: 117417
* First pass at adding logging capabilities for the API functions. At the momentCaroline Tice2010-10-261-0/+27
| | | | | | | | | | | | | | | | | | it logs the function calls, their arguments and the return values. This is not complete or polished, but I am committing it now, at the request of someone who really wants to use it, even though it's not really done. It currently does not attempt to log all the functions, just the most important ones. I will be making further adjustments to the API logging code over the next few days/weeks. (Suggestions for improvements are welcome). Update the Python build scripts to re-build the swig C++ file whenever the python-extensions.swig file is modified. Correct the help for 'log enable' command (give it the correct number & type of arguments). llvm-svn: 117349
* Added the ability to get the disassembly instructions from the function andGreg Clayton2010-10-061-1/+32
| | | | | | symbol. llvm-svn: 115734
* Remove all the __repr__ methods from the API/*.h files, and put themCaroline Tice2010-09-221-10/+3
| | | | | | | | | | into python-extensions.swig, which gets included into lldb.swig, and adds them back into the classes when swig generates it's C++ file. This keeps the Python stuff out of the general API classes. Also fixed a small bug in the copy constructor for SBSymbolContext. llvm-svn: 114602
* Add GetDescription() and __repr__ () methods to most API classes, to allowCaroline Tice2010-09-201-0/+23
| | | | | | | "print" from inside Python to print out the objects in a more useful manner. llvm-svn: 114321
* Very large changes that were needed in order to allow multiple connectionsGreg Clayton2010-06-231-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to the debugger from GUI windows. Previously there was one global debugger instance that could be accessed that had its own command interpreter and current state (current target/process/thread/frame). When a GUI debugger was attached, if it opened more than one window that each had a console window, there were issues where the last one to setup the global debugger object won and got control of the debugger. To avoid this we now create instances of the lldb_private::Debugger that each has its own state: - target list for targets the debugger instance owns - current process/thread/frame - its own command interpreter - its own input, output and error file handles to avoid conflicts - its own input reader stack So now clients should call: SBDebugger::Initialize(); // (static function) SBDebugger debugger (SBDebugger::Create()); // Use which ever file handles you wish debugger.SetErrorFileHandle (stderr, false); debugger.SetOutputFileHandle (stdout, false); debugger.SetInputFileHandle (stdin, true); // main loop SBDebugger::Terminate(); // (static function) SBDebugger::Initialize() and SBDebugger::Terminate() are ref counted to ensure nothing gets destroyed too early when multiple clients might be attached. Cleaned up the command interpreter and the CommandObject and all subclasses to take more appropriate arguments. llvm-svn: 106615
* Initial checkin of lldb code from internal Apple repo.Chris Lattner2010-06-081-0/+64
llvm-svn: 105619
OpenPOWER on IntegriCloud