summaryrefslogtreecommitdiffstats
path: root/lldb/source/API/SBCommandInterpreter.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Don't #include "lldb-python.h" from anywhere.Zachary Turner2015-05-291-2/+0
| | | | | | | | | | | | | Since interaction with the python interpreter is moving towards being more isolated, we won't be able to include this header from normal files anymore, all includes of it should be localized to the python library which will live under source/bindings/API/Python after a future patch. None of the files that were including this header actually depended on it anyway, so it was just a dead include in every single instance. llvm-svn: 238581
* Add support for custom commands to set flags on themselvesEnrico Granata2015-05-271-0/+15
| | | | | | | | | This works for Python commands defined via a class (implement get_flags on your class) and C++ plugin commands (which can call SBCommand::GetFlags()/SetFlags()) Flags allow features such as not letting the command run if there's no target, or if the process is not stopped, ... Commands could always check for these things themselves, but having these accessible via flags makes custom commands more consistent with built-in ones llvm-svn: 238286
* Factor resolution of abbreviations and aliases so that they can be tested ↵Adrian McCarthy2015-04-231-0/+16
| | | | | | directly. http://reviews.llvm.org/D9033 llvm-svn: 235633
* Rework LLDB system initialization.Zachary Turner2015-03-311-177/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | In an effort to reduce binary size for components not wishing to link against all of LLDB, as well as a parallel effort to reduce link dependencies on Python, this patch splits out the notion of LLDB initialization into "full" and "common" initialization. All code related to initializing the full LLDB suite lives directly in API now. Previously it was only referenced from API, but because it was defined in lldbCore, it would get implicitly linked against by everything including lldb-server, causing a considerable increase in binary size. By moving this to the API layer, it also creates a better layering for the ongoing effort to make the embedded interpreter replacable with one from a different language (or even be completely removeable). One semantic change necessary to get this all working was to remove the notion of a shared debugger refcount. The debugger is either initialized or uninitialized now, and calling Initialize() multiple times will simply have no effect, while the first Terminate() will now shut it down no matter how many times Initialize() was called. This behaves nicely with all of our supported usage patterns though, and allows us to fix a number of nasty hacks from before. Differential Revision: http://reviews.llvm.org/D8462 llvm-svn: 233758
* Turn off 'quit' confirmation in lldb-miIlia K2015-03-231-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: # Turn off interpreter.prompt-on-quit on startup (MI) # Add CommandInterpreter::SetPromptOnQuit # Add SBCommandInterpreter::GetPromptOnQuit/SetPromptOnQuit All tests pass on OS X. Test Plan: ``` -file-exec-and-symbols ~/p/hello -break-insert -f main -exec-run -interpreter-exec console quit ``` Reviewers: abidh, clayborg Reviewed By: abidh, clayborg Subscribers: lldb-commits, clayborg, abidh Differential Revision: http://reviews.llvm.org/D8444 llvm-svn: 233034
* Compare pointers directly instead of ::strcmp in SBXxx::EventIsXxxEvent()Ilia K2015-03-211-1/+1
| | | | llvm-svn: 232892
* Fix handling of CommandInterpreter's events in lldb-miIlia K2015-03-211-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously lldb-mi contains a stub for that but it didn't work and all CommanInterpreter's events were ignored. This commit adds a handling of CommandInterpreter's events in lldb-mi. Steps: # Fix CMICmnLLDBDebugger::InitSBListener # Add SBCommandInterpreter::EventIsCommandInterpreterEvent # Exit on lldb::SBCommandInterpreter::eBroadcastBitQuitCommandReceived All tests pass on OS X. In further we can remove "quit" hack in lldb-mi. Test Plan: # Create start_script file: ``` target create ~/p/hello b main r quit ``` # Run lldb-mi --interpreter # Execute start_script file by following command: ``` -interpreter-exec console "command source start_script" ``` Log: ``` $ bin/lldb-mi --interpreter (gdb) -interpreter-exec console "command source start_script" Executing commands in '/Users/IliaK/p/llvm/build_ninja/start_script'. (lldb) target create ~/p/hello Current executable set to '~/p/hello' (x86_64). (lldb) b main Breakpoint 1: where = hello`main + 29 at hello.cpp:12, address = 0x0000000100000e2d (lldb) r Process 1582 launched: '/Users/IliaK/p/hello' (x86_64) (lldb) quit ^done (gdb) =thread-created,id="1",group-id="i1" =thread-selected,id="1" (gdb) =shlibs-added,shlib-info=[num="1",name="hello",dyld-addr="-",reason="dyld",path="/Users/IliaK/p/hello",loaded_addr="-",dsym-objpath="/Users/IliaK/p/hello.dSYM/Contents/Resources/DWARF/hello"] ... =shlibs-added,shlib-info=[num="132",name="libDiagnosticMessagesClient.dylib",dyld-addr="0x7fff91705000",reason="dyld",path="/usr/lib/libDiagnosticMessagesClient.dylib",loaded_addr="0x7fff91705000"] (gdb) *stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={addr="0x100000e2d",func="main",args=[{name="argc",value="1"},{name="argv",value="0x00007fff5fbffc88"}],file="hello.cpp",fullname="/Users/IliaK/p/hello.cpp",line="12"},thread-id="1",stopped-threads="all" (gdb)<press Enter> MI: Program exited OK ``` Reviewers: abidh, clayborg Reviewed By: abidh Subscribers: jingham, lldb-commits, clayborg, abidh Differential Revision: http://reviews.llvm.org/D8382 llvm-svn: 232891
* Fix broadcasters for interpreter and process:Ilia K2015-03-171-2/+1
| | | | | | | | # Fix CommandInterpreter.Broadcaster name (it should be the same as CommandInterpreter::GetStaticBroadcasterClass()) # Prevent the same error in Process.Broadcaster # Fix SBCommandInterpreter::GetBroadcasterClass (it should call CommandInterpreter::GetStaticBroadcasterClass(), was Communication::GetStaticBroadcasterClass()) llvm-svn: 232500
* Handle PyLong return values in LLDBSwigPython_CalculateNumChildren.Siva Chandra2015-03-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: Also, change its return type to size_t to match the return types of its callers. With this change, std::vector and std::list data formatter tests pass on Linux (when using libstdc++) with clang as well as with gcc. These tests have also been enabled in this patch. Test Plan: dotest.py -p <TestDataFormatterStdVector|TestDataFormatterStdList> Reviewers: vharron, clayborg Reviewed By: clayborg Subscribers: zturner, lldb-commits Differential Revision: http://reviews.llvm.org/D8337 llvm-svn: 232399
* Add accessors on SBCommand to get and set the help texts for a commandEnrico Granata2015-03-131-0/+22
| | | | llvm-svn: 232226
* Bulk of the infrastructure work to allow script commands to be backed by ↵Enrico Granata2015-03-131-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | object instances in addition to free functions This works by creating a command backed by a class whose interface should - at least - include def __init__(self, debugger, session_dict) def __call__(self, args, return_obj, exe_ctx) What works: - adding a command via command script add --class - calling a thusly created command What is missing: - support for custom help - test cases The missing parts will follow over the next couple of days This is an improvement over the existing system as: a) it provides an obvious location for commands to provide help strings (i.e. methods) b) it allows commands to store state in an obvious fashion c) it allows us to easily add features to script commands over time (option parsing and subcommands registration, I am looking at you :-) llvm-svn: 232136
* Further reduce header footprint of Debugger.h.Zachary Turner2015-03-041-0/+1
| | | | llvm-svn: 231202
* Enable Python summaries to use custom SBTypeSummaryOptions if the user is so ↵Enrico Granata2014-11-221-0/+1
| | | | | | inclined. Updates to the webdoc will follow llvm-svn: 222593
* Add a feature where a string data formatter can now be partially composed of ↵Enrico Granata2014-10-281-0/+7
| | | | | | | | | | | | | | Python summary functions This works similarly to the {thread/frame/process/target.script:...} feature - you write a summary string, part of which is ${var.script:someFuncName} someFuncName is expected to be declared as def someFuncName(SBValue,otherArgument) - essentially the same as a summary function Since . -> [] are the only allowed separators, and % is used for custom formatting, .script: would not be a legitimate symbol anyway, which makes this non-ambiguous llvm-svn: 220821
* This adds a "batch mode" to lldb kinda like the gdb batch mode. It will ↵Jim Ingham2014-10-141-1/+67
| | | | | | | | | | | | | | | | quit the debugger after all the commands have been executed except if one of the commands was an execution control command that stopped because of a signal or exception. Also adds a variant of SBCommandInterpreter::HandleCommand that takes an SBExecutionContext. That way you can run an lldb command targeted at a particular target, thread or process w/o having to select same before running the command. Also exposes CommandInterpreter::HandleCommandsFromFile to the SBCommandInterpreter API, since that seemed generally useful. llvm-svn: 219654
* Rework the way we pass "run multiple command" options to the various API's thatJim Ingham2014-10-111-0/+94
| | | | | | | | | | | | | | | do that (RunCommandInterpreter, HandleCommands, HandleCommandsFromFile) to gather the options into an options class. Also expose that to the SB API's. Change the way the "-o" options to the lldb driver are processed so: 1) They are run synchronously - didn't really make any sense to run the asynchronously. 2) The stop on error 3) "quit" in one of the -o commands will not quit lldb - not the command interpreter that was running the -o commands. I added an entry to the run options to stop-on-crash, but I haven't implemented that yet. llvm-svn: 219553
* Extend synthetic children to produce synthetic values (as in, those that ↵Enrico Granata2014-10-081-0/+4
| | | | | | | | | | | | | | | | | GetValueAsUnsigned(), GetValueAsCString() would return) The way to do this is to write a synthetic child provider for your type, and have it vend the (optional) get_value function. If get_value is defined, and it returns a valid SBValue, that SBValue's value (as in lldb_private::Value) will be used as the synthetic ValueObject's Value The rationale for doing things this way is twofold: - there are many possible ways to define a "value" (SBData, a Python number, ...) but SBValue seems general enough as a thing that stores a "value", so we just trade values that way and that keeps our currency trivial - we could introduce a new level of layering (ValueObjectSyntheticValue), a new kind of formatter (synthetic value producer), but that would complicate the model (can I have a dynamic with no synthetic children but synthetic value? synthetic value with synthetic children but no dynamic?), and I really couldn't see much benefit to be reaped from this added complexity in the matrix On the other hand, just defining a synthetic child provider with a get_value but returning no actual children is easy enough that it's not a significant road-block to adoption of this feature Comes with a test case llvm-svn: 219330
* Allow Python commands to optionally take an SBExecutionContext argument in ↵Enrico Granata2014-10-011-1/+2
| | | | | | case they need to handle 'where they want to act' separately from the notion of 'currently-selected entity' that is associated to the debugger. Do this in an (hopefully) non-breaking way by running an argcount check before passing in the new argument. Update the test case to also check for this new feature. www update to follow llvm-svn: 218834
* This checkin is the first step in making the lldb thread stepping mechanism ↵Jim Ingham2014-09-291-1/+14
| | | | | | | | | | | | more accessible from the user level. It adds the ability to invent new stepping modes implemented by python classes, and to view the current thread plan stack and to some extent alter it. I haven't gotten to documentation or tests yet. But this should not cause any behavior changes if you don't use it, so its safe to check it in now and work on it incrementally. llvm-svn: 218642
* Any commands that are executed through the public interface using ↵Greg Clayton2014-07-151-0/+1
| | | | | | | | | | | | | | SBCommandInterpreter::HandleCommand() are assumed to be in non-interactive mode. Any commands that want interactivity (stdin) will need to be executed through the normal command interpreter using the debugger's in/out/err file handles, or by using "command source". Individual commands through the API will have their STDIN disabled. The STDOUT and STDERR will be redirected into the SBCommandReturnObject argument to SBCommandInterpreter::HandleCommand() as usual. This helps with a deadlock situation in an IDE (Xcode) where the IDE was managing the breakpoint actions by setting a breakpoint callback and doing things manually. <rdar://problem/17386271> llvm-svn: 213023
* sweep up -Wformat warnings from gccSaleem Abdulrasool2014-04-041-22/+32
| | | | | | | 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
* sanitise sign comparisonsSaleem Abdulrasool2014-04-021-1/+2
| | | | | | | | 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
* Merging the iohandler branch back into main. Greg Clayton2014-01-271-0/+16
| | | | | | | | | | | | The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
* Roll back the changes I made in r193907 which created a new FrameJason Molenda2013-11-041-3/+3
| | | | | | | | | | pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
* Add a new base class, Frame. It is a pure virtual function whichJason Molenda2013-11-021-3/+3
| | | | | | | | | | | | | | | | | | | | | defines a protocol that all subclasses will implement. StackFrame is currently the only subclass and the methods that Frame vends are nearly identical to StackFrame's old methods. Update all callers to use Frame*/Frame& instead of pointers to StackFrames. This is almost entirely a mechanical change that touches a lot of the code base so I'm committing it alone. No new functionality is added with this patch, no new subclasses of Frame exist yet. I'll probably need to tweak some of the separation, possibly moving some of StackFrame's methods up in to Frame, but this is a good starting point. <rdar://problem/15314068> llvm-svn: 193907
* Fixed the MacOSX non "Debug" builds so that "lldb-platform" doesn't fail to ↵Greg Clayton2013-10-171-9/+116
| | | | | | link. llvm-svn: 192857
* <rdar://problem/13521159>Greg Clayton2013-03-271-8/+8
| | | | | | | | 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
* <rdar://problem/12586010>Greg Clayton2013-01-081-4/+0
| | | | | | | | Python OS plug-ins now fetch thread registers lazily. Also changed SBCommandInterpreter::HandleCommand() to not take the API lock. The logic here is that from the command line you can execute a command that might result in another thread (like the private process thread) to execute python or run any code that can re-enter the public API. When this happens, a deadlock immediately occurs for things like "process launch" and "process attach". llvm-svn: 171901
* Fix Linux build warnings due to redefinition of macros:Daniel Malea2012-12-051-0/+2
| | | | | | | | | - add new header lldb-python.h to be included before other system headers - short term fix (eventually python dependencies must be cleaned up) Patch by Matt Kopec! llvm-svn: 169341
* Resolve printf formatting warnings on Linux:Daniel Malea2012-11-291-1/+1
| | | | | | | | - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
* Added a new "module" log channel which covers module creation, deletion, and ↵Greg Clayton2012-10-081-1/+1
| | | | | | | | | | common module list actions. Also added a new option for "log enable" which is "--stack" which will print out a stack backtrace for each log line. This was used to track down the leaking module issue I fixed last week. llvm-svn: 165438
* Implementing plugins that provide commands.Enrico Granata2012-09-281-2/+124
| | | | | | | | | | | | | | | | | | | This checkin adds the capability for LLDB to load plugins from external dylibs that can provide new commands It exports an SBCommand class from the public API layer, and a new SBCommandPluginInterface There is a minimal load-only plugin manager built into the debugger, which can be accessed via Debugger::LoadPlugin. Plugins are loaded from two locations at debugger startup (LLDB.framework/Resources/PlugIns and ~/Library/Application Support/LLDB/PlugIns) and more can be (re)loaded via the "plugin load" command For an example of how to make a plugin, refer to the fooplugin.cpp file in examples/plugins/commands Caveats: Currently, the new API objects and features are not exposed via Python. The new commands can only be "parsed" (i.e. not raw) and get their command line via a char** parameter (we do not expose our internal Args object) There is no unloading feature, which can potentially lead to leaks if you overwrite the commands by reloading the same or different plugins There is no API exposed for option parsing, which means you may need to use getopt or roll-your-own llvm-svn: 164865
* Change UnwindAssemblyInstEmulation::GetNonCallSiteUnwindPlanFromAssembly so ↵Jason Molenda2012-07-171-2/+2
| | | | | | | | | | | | | | | | it records the state of the unwind instructions once the prologue has finished. If it hits an early return epilogue in the middle of the function, re-instate the prologue after that epilogue has completed so that we can still unwind for cases where the flow of control goes past that early-return. <rdar://problem/11775059> Move the UnwindPlan operator== definition into the .cpp file, expand the definition a bit. Add some casts to a SBCommandInterpreter::HandleCompletion() log statement so it builds without warning on 64- and 32-bit systems. llvm-svn: 160337
* Add API logging to SBCommandInterpreter::HandleCompletion().Jim Ingham2012-06-261-0/+8
| | | | llvm-svn: 159180
* <rdar://problem/11328896> Fixing a bug where regex commands were saved in ↵Enrico Granata2012-05-311-1/+1
| | | | | | the history even if they came from a 'command sourced' file - this fix introduces a command sourcing depth and disables history for all levels of depth > 0, which means no commands go into history when being sourced from a file. we need an integer depth because command files might themselves source other command files, ... llvm-svn: 157727
* <rdar://problem/10605072>Greg Clayton2012-05-081-1/+3
| | | | | | Fixed the command callback override lookup function so we can now override the "process launch" command (or any other multi-word commands). llvm-svn: 156368
* Don't expose the pthread_mutex_t underlying the Mutex & Mutex::Locker classes. Jim Ingham2012-05-041-3/+3
| | | | | | | | | | | | | 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-3/+3
| | | | | | | | 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
* <rdar://problem/10605072>Greg Clayton2012-02-291-0/+17
| | | | | | | | | | | | | Added the ability to override command line commands. In some cases GUI interfaces might want to intercept commands like "quit" or "process launch" (which might cause the process to re-run). They can now do so by overriding/intercepting commands by using functions added to SBCommandInterpreter using a callback function. If the callback function returns true, the command is assumed to be handled. If false is returned the command should be evaluated normally. Adopted this up in the Driver.cpp for intercepting the "quit" command. llvm-svn: 151708
* This commit:Enrico Granata2012-02-291-59/+1
| | | | | | | | | | | | | a) adds a Python summary provider for NSDate b) changes the initialization for ScriptInterpreter so that we are not passing a bulk of Python-specific function pointers around c) provides a new ScriptInterpreterObject class that allows for ref-count safe wrapping of scripting objects on the C++ side d) contains much needed performance improvements: 1) the pointer to the Python function generating a scripted summary is now cached instead of looked up every time 2) redundant memory reads in the Python ObjC runtime wrapper are eliminated 3) summaries now use the m_summary_str in ValueObject to store their data instead of passing around ( == copying) an std::string object e) contains other minor fixes, such as adding descriptive error messages for some cases of summary generation failure llvm-svn: 151703
* Add a general mechanism to wait on the debugger for Broadcasters of a given ↵Jim Ingham2012-02-161-0/+6
| | | | | | | | | class/event bit set. Use this to allow the lldb Driver to emit notifications for breakpoint modifications. <rdar://problem/10619974> llvm-svn: 150665
* SBFrame is now threadsafe using some extra tricks. One issue is that stackGreg Clayton2012-01-301-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* <rdar://problem/10750012>Greg Clayton2012-01-271-26/+0
| | | | | | | | Remove a pseudo terminal master open and slave file descriptor that was being used for pythong stdin. It was not hooked up correctly and was causing file descriptor leaks. llvm-svn: 149098
* Work in progress for:Johnny Chen2011-12-191-4/+4
| | | | | | | | | rdar://problem/10577182 Audit lldb API impl for places where we need to perform a NULL check Add NULL checks for SBCommandInterpreter APIs. llvm-svn: 146909
* Sanity check the inputs to SBCommandInterpreter::HandleCompletionJim Ingham2011-12-051-0/+13
| | | | llvm-svn: 145840
* Fixed the Xcode project building of LLVM to be a bit more user friendly:Greg Clayton2011-11-041-0/+16
| | | | | | | | | | | | | | | | | | | - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
* this patch introduces a new command script import command which takes as ↵Enrico Granata2011-10-171-1/+9
| | | | | | input a filename for a Python script and imports the module contained in that file. the containing directory is added to the Python path such that dependencies are honored. also, the module may contain an __lldb_init_module(debugger,dict) function, which gets called after importing, and which can somehow initialize the module's interaction with lldb llvm-svn: 142283
* Add a new breakpoint type "break by source regular expression".Jim Ingham2011-09-211-0/+12
| | | | | | | | | Fix the RegularExpression class so it has a real copy constructor. Fix the breakpoint setting with multiple shared libraries so it makes one breakpoint not one per shared library. Add SBFileSpecList, to be used to expose the above to the SB interface (not done yet.) llvm-svn: 140225
* SBSourceManager now gets the real source manager either from the Debugger or ↵Jim Ingham2011-09-131-1/+0
| | | | | | | | Target. Also, move the SourceManager file cache into the debugger so it can be shared amongst the targets. llvm-svn: 139564
* Redesign of the interaction between Python and frozen objects:Enrico Granata2011-09-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
OpenPOWER on IntegriCloud