summaryrefslogtreecommitdiff
path: root/lldb/source/Target/StackFrame.cpp
AgeCommit message (Collapse)Author
2011-07-06Fixed some issues with ARM backtraces by not processing any push/pop Greg Clayton
instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06new syntax for summary strings:Enrico Granata
- ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-06-22Fixed an issue where SBFrame::GetDisassembly() was returning disassembly thatGreg Clayton
contained the current line marker. This is now an option which is not enabled for the API disassembly call. llvm-svn: 133597
2011-06-17Fixed variable parsing to not parse block variables over and over due to anGreg Clayton
issue in the way block variables are marked as parsed. In the DWARF parser we always parse all blocks for a function at once, so we can mark all blocks as having all variables parsed and avoid recursive function calls to try and reparse things that have already been handled. Fixed an issue with how variables get scoped into blocks. The DWARF parser can now handle abtract class definitions that contain concrete static variables. When the concrete instance of the class functions get instantiated, they will track down the concrete block for the abtract block and add the variable to each block. llvm-svn: 133302
2011-05-04Change "frame var" over to using OptionGroups (and thus the ↵Jim Ingham
OptionGroupVariableObjectDisplay). Change the boolean "use_dynamic" over to a tri-state, no-dynamic, dynamic-w/o running target, and dynamic with running target. llvm-svn: 130832
2011-04-23Fixed the SymbolContext::DumpStopContext() to correctly indent and dumpGreg Clayton
inline contexts when the deepest most block is not inlined. Added source path remappings to the lldb_private::Target class that allow it to remap paths found in debug info so we can find source files that are elsewhere on the current system. Fixed disassembly by function name to disassemble inline functions that are inside other functions much better and to show enough context before the disassembly output so you can tell where things came from. Added the ability to get more than one address range from a SymbolContext class for the case where a block or function has discontiguous address ranges. llvm-svn: 130044
2011-04-22Fix up how the ValueObjects manage their life cycle so that you can hand out ↵Jim Ingham
a shared pointer to a ValueObject or any of its dependent ValueObjects, and the whole cluster will stay around as long as that shared pointer stays around. llvm-svn: 130035
2011-04-18Centralized a lot of the status information for processes,Greg Clayton
threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-16Add support for "dynamic values" for C++ classes. This currently only works ↵Jim Ingham
for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-03-31Convert ValueObject to explicitly maintain the Execution Context in which ↵Jim Ingham
they were created, and then use that when they update themselves. That means all the ValueObject evaluate me type functions that used to require a Frame object now do not. I didn't remove the SBValue API's that take this now useless frame, but I added ones that don't require the frame, and marked the SBFrame taking ones as deprecated. llvm-svn: 128593
2011-03-25Cleaned up the Disassembler code a bit more. You can now request a disassemblerGreg Clayton
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
2011-03-22Add the ability to disassemble "n" instructions from the current PC, or the ↵Jim Ingham
first "n" instructions in a function. Also added a "-p" flag that disassembles from the current pc. llvm-svn: 128063
2011-03-10Fixed the -r parameter to the disassemble commandSean Callanan
so that it actually triggers raw output. llvm-svn: 127433
2011-02-15Made lldb_private::ArchSpec contain much more than just an architecture. ItGreg Clayton
now, in addition to cpu type/subtype and architecture flavor, contains: - byte order (big endian, little endian) - address size in bytes - llvm::Triple for true target triple support and for more powerful plug-in selection. llvm-svn: 125602
2011-01-25Enabled extra warnings and fixed a bunch of small issues.Greg Clayton
llvm-svn: 124250
2011-01-20Added the ability to StackFrame::GetValueForVariableExpressionPath(...) to avoidGreg Clayton
fragile ivars if requested. This was done by changing the previous second parameter to an options bitfield that can be populated by logical OR'ing the new StackFrame::ExpressionPathOption enum values together: typedef enum ExpressionPathOption { eExpressionPathOptionCheckPtrVsMember = (1u << 0), eExpressionPathOptionsNoFragileObjcIvar = (1u << 1), }; So the old function was: lldb::ValueObjectSP StackFrame::GetValueForVariableExpressionPath (const char *var_expr, bool check_ptr_vs_member, Error &error); But it is now: lldb::ValueObjectSP StackFrame::GetValueForVariableExpressionPath (const char *var_expr, uint32_t options, Error &error); This allows the expression parser in Target::EvaluateExpression(...) to avoid using simple frame variable expression paths when evaluating something that might be a fragile ivar. llvm-svn: 123938
2011-01-17A few of the issue I have been trying to track down and fix have been due toGreg Clayton
the way LLDB lazily gets complete definitions for types within the debug info. When we run across a class/struct/union definition in the DWARF, we will only parse the full definition if we need to. This works fine for top level types that are assigned directly to variables and arguments, but when we have a variable with a class, lets say "A" for this example, that has a member: "B *m_b". Initially we don't need to hunt down a definition for this class unless we are ever asked to do something with it ("expr m_b->getDecl()" for example). With my previous approach to lazy type completion, we would be able to take a "A *a" and get a complete type for it, but we wouldn't be able to then do an "a->m_b->getDecl()" unless we always expanded all types within a class prior to handing out the type. Expanding everything is very costly and it would be great if there were a better way. A few months ago I worked with the llvm/clang folks to have the ExternalASTSource class be able to complete classes if there weren't completed yet: class ExternalASTSource { .... virtual void CompleteType (clang::TagDecl *Tag); virtual void CompleteType (clang::ObjCInterfaceDecl *Class); }; This was great, because we can now have the class that is producing the AST (SymbolFileDWARF and SymbolFileDWARFDebugMap) sign up as external AST sources and the object that creates the forward declaration types can now also complete them anywhere within the clang type system. This patch makes a few major changes: - lldb_private::Module classes now own the AST context. Previously the TypeList objects did. - The DWARF parsers now sign up as an external AST sources so they can complete types. - All of the pure clang type system wrapper code we have in LLDB (ClangASTContext, ClangASTType, and more) can now be iterating through children of any type, and if a class/union/struct type (clang::RecordType or ObjC interface) is found that is incomplete, we can ask the AST to get the definition. - The SymbolFileDWARFDebugMap class now will create and use a single AST that all child SymbolFileDWARF classes will share (much like what happens when we have a complete linked DWARF for an executable). We will need to modify some of the ClangUserExpression code to take more advantage of this completion ability in the near future. Meanwhile we should be better off now that we can be accessing any children of variables through pointers and always be able to resolve the clang type if needed. llvm-svn: 123613
2011-01-06Fixed issues with RegisterContext classes and the subclasses. There wasGreg Clayton
an issue with the way the UnwindLLDB was handing out RegisterContexts: it was making shared pointers to register contexts and then handing out just the pointers (which would get put into shared pointers in the thread and stack frame classes) and cause double free issues. MallocScribble helped to find these issues after I did some other cleanup. To help avoid any RegisterContext issue in the future, all code that deals with them now returns shared pointers to the register contexts so we don't end up with multiple deletions. Also now that the RegisterContext class doesn't require a stack frame, we patched a memory leak where a StackFrame object was being created and leaked. Made the RegisterContext class not have a pointer to a StackFrame object as one register context class can be used for N inlined stack frames so there is not a 1 - 1 mapping. Updates the ExecutionContextScope part of the RegisterContext class to never return a stack frame to indicate this when it is asked to recreate the execution context. Now register contexts point to the concrete frame using a concrete frame index. Concrete frames are all of the frames that are actually formed on the stack of a thread. These concrete frames can be turned into one or more user visible frames due to inlining. Each inlined stack frame has the exact same register context (shared via shared pointers) as any parent inlined stack frames all the way up to the concrete frame itself. So now the stack frames and the register contexts should behave much better. llvm-svn: 122976
2010-12-20The LLDB API (lldb::SB*) is now thread safe!Greg Clayton
llvm-svn: 122262
2010-12-15Fixed the "expression" command object to use the ↵Greg Clayton
StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-14Modified LLDB expressions to not have to JIT and run code just to see variableGreg Clayton
values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-11-20Change the DWARFExpression::Evaluate methods to take an optionalJason Molenda
RegisterContext* - normally this is retrieved from the ExecutionContext's StackFrame but when we need to evaluate an expression while creating the stack frame list this can be a little tricky. Add DW_OP_deref_size, needed for the _sigtramp FDE expression. Add support for processing DWARF expressions in RegisterContextLLDB. Update callers to DWARFExpression::Evaluate. llvm-svn: 119885
2010-11-01Fixed StackFrame::GetVariableList to add globalSean Callanan
variables to the list of found variables if they have not yet been added. llvm-svn: 117896
2010-10-27Updated the lldb_private::Flags class to have better method names and madeGreg Clayton
all of the calls inlined in the header file for better performance. Fixed the summary for C string types (array of chars (with any combo if modifiers), and pointers to chars) work in all cases. Fixed an issue where a forward declaration to a clang type could cause itself to resolve itself more than once if, during the resolving of the type itself it caused something to try and resolve itself again. We now remove the clang type from the forward declaration map in the DWARF parser when we start to resolve it and avoid this additional call. This should stop any duplicate members from appearing and throwing all the alignment of structs, unions and classes. llvm-svn: 117437
2010-10-04There are now to new "settings set" variables that live in each debuggerGreg Clayton
instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-09-23Add GetSP to the StackFrame.Jim Ingham
llvm-svn: 114674
2010-09-14Moved the section load list up into the target so we can use the targetGreg Clayton
to symbolicate things without the need for a valid process subclass. llvm-svn: 113895
2010-09-14Looking at some of the test suite failures in DWARF in .o files with theGreg Clayton
debug map showed that the location lists in the .o files needed some refactoring in order to work. The case that was failing was where a function that was in the "__TEXT.__textcoal_nt" in the .o file, and in the "__TEXT.__text" section in the main executable. This made symbol lookup fail due to the way we were finding a real address in the debug map which was by finding the section that the function was in in the .o file and trying to find this in the main executable. Now the section list supports finding a linked address in a section or any child sections. After fixing this, we ran into issue that were due to DWARF and how it represents locations lists. DWARF makes a list of address ranges and expressions that go along with those address ranges. The location addresses are expressed in terms of a compile unit address + offset. This works fine as long as nothing moves around. When stuff moves around and offsets change between the remapped compile unit base address and the new function address, then we can run into trouble. To deal with this, we now store supply a location list slide amount to any location list expressions that will allow us to make the location list addresses into zero based offsets from the object that owns the location list (always a function in our case). With these fixes we can now re-link random address ranges inside the debugger for use with our DWARF + debug map, incremental linking, and more. Another issue that arose when doing the DWARF in the .o files was that GCC 4.2 emits a ".debug_aranges" that only mentions functions that are externally visible. This makes .debug_aranges useless to us and we now generate a real address range lookup table in the DWARF parser at the same time as we index the name tables (that are needed because .debug_pubnames is just as useless). llvm-gcc doesn't generate a .debug_aranges section, though this could be fixed, we aren't going to rely upon it. Renamed a bunch of "UINT_MAX" to "UINT32_MAX". llvm-svn: 113829
2010-09-13Fixed an assertion that happened when debugging DWARF in .o files with debugGreg Clayton
map on macosx. llvm-svn: 113737
2010-09-07Added more API to lldb::SBBlock to allow getting the blockGreg Clayton
parent, sibling and first child block, and access to the inline function information. Added an accessor the StackFrame: Block * lldb_private::StackFrame::GetFrameBlock(); LLDB represents inline functions as lexical blocks that have inlined function information in them. The function above allows us to easily get the top most lexical block that defines a stack frame. When there are no inline functions in function, the block returned ends up being the top most block for the function. When the PC is in an inlined funciton for a frame, this will return the first parent block that has inlined function information. The other accessor: StackFrame::GetBlock() will return the deepest block that matches the frame's PC value. Since most debuggers want to display all variables in the current frame, the Block returned by StackFrame::GetFrameBlock can be used to retrieve all variables for the current frame. Fixed the lldb_private::Block::DumpStopContext(...) to properly display inline frames a block should display all of its inlined functions. Prior to this fix, one of the call sites was being skipped. This is a separate code path from the current default where inlined functions get their own frames. Fixed an issue where a block would always grab variables for any child inline function blocks. llvm-svn: 113195
2010-09-03Fixed the StackFrame to correctly resolve the StackID's SymbolContextScope.Greg Clayton
Added extra logging for stepping. Fixed an issue where cached stack frame data could be lost between runs when the thread plans read a stack frame. llvm-svn: 112973
2010-09-02Added a new bool parameter to many of the DumpStopContext() methods that Greg Clayton
might dump file paths that allows the dumping of full paths or just the basenames. Switched the stack frame dumping code to use just the basenames for the files instead of the full path. Modified the StackID class to no rely on needing the start PC for the current function/symbol since we can use the SymbolContextScope to uniquely identify that, unless there is no symbol context scope. In that case we can rely upon the current PC value. This saves the StackID from having to calculate the start PC when the StackFrame::GetStackID() accessor is called. Also improved the StackID less than operator to correctly handle inlined stack frames in the same stack. llvm-svn: 112867
2010-09-02StackFrame objects now own ValueObjects for any frame variables (locals, args,Greg Clayton
function statics, file globals and static variables) that a frame contains. The StackFrame objects can give out ValueObjects instances for each variable which allows us to track when a variable changes and doesn't depend on variable names when getting value objects. StackFrame::GetVariableList now takes a boolean to indicate if we want to get the frame compile unit globals and static variables. The value objects in the stack frames can now correctly track when they have been modified. There are a few more tweaks needed to complete this work. The biggest issue is when stepping creates partial stacks (just frame zero usually) and causes previous stack frames not to match up with the current stack frames because the previous frames only has frame zero. We don't really want to require that all previous frames be complete since stepping often must check stack frames to complete their jobs. I will fix this issue tomorrow. llvm-svn: 112800
2010-08-30Clarified the intent of the SymbolContextScope class in the headerGreg Clayton
documentation. Symbol now inherits from the symbol context scope so that the StackID can use a "SymbolContextScope *" instead of a blockID (which could have been the same as some other blockID from another symbol file). Modified the stacks that are created on subsequent stops to reuse the previous stack frame objects which will allow for some internal optimization using pointer comparisons during stepping. llvm-svn: 112495
2010-08-27Made it so we update the current frames from the previous frames by doing STLGreg Clayton
swaps on the variable list, value object list, and disassembly. This avoids us having to try and update frame indexes and other things that were getting out of sync. llvm-svn: 112301
2010-08-27Simplified the StackFrameList class down to a single frames list againGreg Clayton
instead of trying to maintain the real frame list (unwind frames) and an inline frame list. The information is cheap to produce when we already have looked up a block and was making stack frame uniquing difficult when trying to use the previous stack when making the current stack. We now maintain the previous value object lists for common frames between a previous and current frames so we will be able to tell when variable values change. llvm-svn: 112277
2010-08-26Changed the StackID to store its start PC address as a load address instead of Greg Clayton
a section offset address. Fixed up some very inefficient STL code. llvm-svn: 112230
2010-08-26Add StackFrame::IsInlined.Jim Ingham
llvm-svn: 112217
2010-08-26Cleaned up the inline stack frame code one more time to prepare for inlinedGreg Clayton
code stepping. Also we now store the stack frames for the current and previous stops in the thread in std::auto_ptr objects. When we create a thread stack frame list we pass the previous frame into it so it can re-use the frames and maintain will allow for variable changes to be detected. I will implement the stack frame reuse next. llvm-svn: 112152
2010-08-24Fixed another issue with the inline stack frames where if the first frameGreg Clayton
has inlined functions that all started at the same address, then the inlined backtrace would not produce correct stack frames. Also cleaned up and inlined a lot of stuff in lldb_private::Address. Added a function to StackFrame to detect if the frame is a concrete frame so we can detect the difference between actual frames and inlined frames. llvm-svn: 111989
2010-08-24Got a lot of the kinks worked out in the inline support after debugging moreGreg Clayton
complex inlined examples. StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()". This is because inlined frames will have a PC value that is the same as the concrete frame that owns the inlined frame, yet the code locations for the frame can be different. We also need to be able to get the real PC value for a given frame so that variables evaluate correctly. To get the actual PC value for a frame you can use: addr_t pc = frame->GetRegisterContext()->GetPC(); Some issues with the StackFrame stomping on its own symbol context were resolved which were causing the information to change for a frame when the stack ID was calculated. Also the StackFrame will now correctly store the symbol context resolve flags for any extra bits of information that were looked up (if you ask for a block only and you find one, you will alwasy have the compile unit and function). llvm-svn: 111964
2010-08-24Added support for inlined stack frames being represented as real stack framesGreg Clayton
which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-21Modified the host process monitor callback function ↵Greg Clayton
Host::StartMonitoringChildProcess to spawn a thread for each process that is being monitored. Previously LLDB would spawn a single thread that would wait for any child process which isn't ok to do as a shared library (LLDB.framework on Mac OSX, or lldb.so on linux). The old single thread used to call wait4() with a pid of -1 which could cause it to reap child processes that it shouldn't have. Re-wrote the way Function blocks are handles. Previously I attempted to keep all blocks in a single memory allocation (in a std::vector). This made the code somewhat efficient, but hard to work with. I got rid of the old BlockList class, and went to a straight parent with children relationship. This new approach will allow for partial parsing of the blocks within a function. llvm-svn: 111706
2010-06-30Centralized all disassembly into static functions in ↵Greg Clayton
source/Core/Disassembler.cpp. Added the ability to read memory from the target's object files when we aren't running, so disassembling works before you run! Cleaned up the API to lldb_private::Target::ReadMemory(). Cleaned up the API to the Disassembler to use actual "lldb_private::Address" objects instead of just an "addr_t". This is nice because the Address objects when resolved carry along their section and module which can get us the object file. This allows Target::ReadMemory to be used when we are not running. Added a new lldb_private::Address dump style: DumpStyleDetailedSymbolContext This will show a full breakdown of what an address points to. To see some sample output, execute a "image lookup --address <addr>". Fixed SymbolContext::DumpStopContext(...) to not require a live process in order to be able to print function and symbol offsets. llvm-svn: 107350
2010-06-23Very large changes that were needed in order to allow multiple connectionsGreg Clayton
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
2010-06-08Initial checkin of lldb code from internal Apple repo.Chris Lattner
llvm-svn: 105619