than just the entire log channel.
Add checks, where appropriate, to make sure a log channel/category has
not been disabled before attempting to write to it.
llvm-svn: 117715
by type ID (the most common type of type lookup).
Changed the API logging a bit to always show the objects in the OBJECT(POINTER)
format so it will be easy to locate all instances of an object or references
to it when looking at logs.
llvm-svn: 117641
which holds the name of a file whose contents are
prefixed to each expression. For example, if the file
~/lldb.prefix.header contains:
typedef unsigned short my_type;
then you can do this:
(lldb) settings set target.expr-prefix '~/lldb.prefix.header'
(lldb) expr sizeof(my_type)
(unsigned long) $0 = 2
When the variable is changed, the corresponding file
is loaded and its contents are fetched into a string
that is stored along with the target. This string
is then passed to each expression and inserted into
it during parsing, like this:
typedef unsigned short my_type;
void
$__lldb_expr(void *$__lldb_arg)
{
sizeof(my_type);
}
llvm-svn: 117627
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
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
Not yet enabled as the default unwinder but there are no known
backtrace problems with the code at this point.
Added 'log enable lldb unwind' to help diagnose backtrace problems;
this output needs a little refining but it's a good first step.
eh_frame information is currently read unconditionally - the code
is structured to allow this to be delayed until it's actually needed.
There is a performance hit when you have to parse the eh_frame
information for any largeish executable/library so it's necessary
to avoid if possible.
It's confusing having both the UnwindPlan::RegisterLocation struct
and the RegisterConextLLDB::RegisterLocation struct, I need to rename
one of them.
The writing of registers isn't done in the RegisterConextLLDB subclass
yet; neither is the running of complex DWARF expressions from eh_frame
(e.g. used for _sigtramp on Mac OS X).
llvm-svn: 117256
sockets so the driver doesn't just crash.
Added support for connecting to named sockets (unix IPC sockets) in
ConnectionFileDescriptor.
Modified the Host::LaunchInNewTerminal() for MacOSX to return the process
ID of the inferior process instead of the process ID of the Terminal.app. This
was done by modifying the "darwin-debug" executable to connect to lldb through
a named unix socket which is passed down as an argument. This allows a quick
handshake between "lldb" and "darwin-debug" so we can get the process ID
of the inferior and then attach by process ID and avoid attaching to the
inferior by process name since there could be more than one process with
that name. This still has possible race conditions, those will be fixed
in the near future. This fixes the SIGPIPE issues that were sometimes being
seen when task_for_pid was failing.
llvm-svn: 116792
but something is still killing our inferior.
Fixed an issue with darwin-debug where it wasn't passing all needed arguments
to the inferior.
Fixed a race condition with the attach to named process code.
llvm-svn: 116697
"vAttachName;<PROCNAME>" packet, and wait for a new process by name to launch
with the "vAttachWait;<PROCNAME>".
Fixed a few issues with attaching where if DoAttach() returned no error, yet
there was no valid process ID, we would deadlock waiting for an event that
would never happen.
Added a new "process launch" option "--tty" that will launch the process
in a new terminal if the Host layer supports the "Host::LaunchInNewTerminal(...)"
function. This currently works on MacOSX and will allow the debugging of
terminal applications that do complex operations with the terminal.
Cleaned up the output when the process resumes, stops and halts to be
consistent with the output format.
llvm-svn: 116693
static bool
Host::GetLLDBPath (lldb::PathType path_type, FileSpec &file_spec);
This will fill in "file_spec" with an appropriate path that is appropriate
for the current Host OS. MacOSX will return paths within the LLDB.framework,
and other unixes will return the paths they want. The current PathType
enums are:
typedef enum PathType
{
ePathTypeLLDBShlibDir, // The directory where the lldb.so (unix) or LLDB mach-o file in LLDB.framework (MacOSX) exists
ePathTypeSupportExecutableDir, // Find LLDB support executable directory (debugserver, etc)
ePathTypeHeaderDir, // Find LLDB header file directory
ePathTypePythonDir // Find Python modules (PYTHONPATH) directory
} PathType;
All places that were finding executables are and python paths are now updated
to use this Host call.
Added another new host call to launch the inferior in a terminal. This ability
will be very host specific and doesn't need to be supported on all systems.
MacOSX currently will create a new .command file and tell Terminal.app to open
the .command file. It also uses the new "darwin-debug" app which is a small
app that uses posix to exec (no fork) and stop at the entry point of the
program. The GDB remote plug-in is almost able launch a process and attach to
it, it currently will spawn the process, but it won't attach to it just yet.
This will let LLDB not have to share the terminal with another process and a
new terminal window will pop up when you launch. This won't get hooked up
until we work out all of the kinks. The new Host function is:
static lldb::pid_t
Host::LaunchInNewTerminal (
const char **argv, // argv[0] is executable
const char **envp,
const ArchSpec *arch_spec,
bool stop_at_entry,
bool disable_aslr);
Cleaned up FileSpec::GetPath to not use strncpy() as it was always zero
filling the entire path buffer.
Fixed an issue with the dynamic checker function where I missed a '$' prefix
that should have been added.
llvm-svn: 116690
Add missing break statment to case statement in Process::ShouldBroadcastEvent.
Add new command, "process handle" to allow users to control process behavior on
the receipt of various Unix signals (whether the process should stop; whether the
process should be passed the signal; whether the debugger user should be notified
that the signal came in).
llvm-svn: 116430
Added frame relative frame selection to "frame select". You can now select
frames relative to the current frame (which defaults to zero if the current
frame hasn't yet been set for a thread):
The gdb "up" command can be done as:
(lldb) frame select -r 1
The gdb "down" command can be done as:
(lldb) frame select -r -1
Place the following in your ~/.lldbinit file for "up" and "down":
command alias up frame select -r 1
command alias down frame select -r -1
llvm-svn: 116176
if the address comes from a data section.
Fixed an issue that could occur when looking up a symbol that has a zero
byte size where no match would be returned even if there was an exact symbol
match.
Cleaned up the section dump output and added the section type into the output.
llvm-svn: 116017
tricks to get types to resolve. I did this by correctly including the correct
files: stdint.h and all lldb-*.h files first before including the API files.
This allowed me to remove all of the hacks that were in the lldb.swig file
and it also allows all of the #defines in lldb-defines.h and enumerations
in lldb-enumerations.h to appear in the lldb.py module. This will make the
python script code a lot more readable.
Cleaned up the "process launch" command to not execute a "process continue"
command, it now just does what it should have with the internal API calls
instead of executing another command line command.
Made the lldb_private::Process set the state to launching and attaching if
WillLaunch/WillAttach return no error respectively.
llvm-svn: 115902
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
Change default 'set' behavior so that all instance settings for the specified variable will be
updated, unless the "-n" ("--no_override") command options is specified.
llvm-svn: 114808
for C++ classes. Replaced it with a less hacky approach:
- If an expression is defined in the context of a
method of class A, then that expression is wrapped as
___clang_class::___clang_expr(void*) { ... }
instead of ___clang_expr(void*) { ... }.
- ___clang_class is resolved as the type of the target
of the "this" pointer in the method the expression
is defined in.
- When reporting the type of ___clang_class, a method
with the signature ___clang_expr(void*) is added to
that class, so that Clang doesn't complain about a
method being defined without a corresponding
declaration.
- Whenever the expression gets called, "this" gets
looked up, type-checked, and then passed in as the
first argument.
This required the following changes:
- The ABIs were changed to support passing of the "this"
pointer as part of trivial calls.
- ThreadPlanCallFunction and ClangFunction were changed
to support passing of an optional "this" pointer.
- ClangUserExpression was extended to perform the
wrapping described above.
- ClangASTSource was changed to revert the changes
required by the hack.
- ClangExpressionParser, IRForTarget, and
ClangExpressionDeclMap were changed to handle
different manglings of ___clang_expr flexibly. This
meant no longer searching for a function called
___clang_expr, but rather looking for a function whose
name *contains* ___clang_expr.
- ClangExpressionParser and ClangExpressionDeclMap now
remember whether "this" is required, and know how to
look it up as necessary.
A few inheritance bugs remain, and I'm trying to resolve
these. But it is now possible to use "this" as well as
refer implicitly to member variables, when in the proper
context.
llvm-svn: 114384
the parent of Process settings; add 'default-arch' as a
class-wide setting for Target. Replace lldb::GetDefaultArchitecture
with Target::GetDefaultArchitecture & Target::SetDefaultArchitecture.
Add 'use-external-editor' as user setting to Debugger class & update
code appropriately.
Add Error parameter to methods that get user settings, for easier
reporting of bad requests.
Fix various other minor related bugs.
Fix test cases to work with new changes.
llvm-svn: 114352
replacing the "(lldb)" prompt, the "frame #1..." displays when doing
stack backtracing and the "thread #1....". This will allow you to see
exactly the information that you want to see where you want to see it.
This currently isn't hookup up to the prompts yet, but it will be soon.
So what is the format of the prompts? Prompts can contain variables that
have access to the current program state. Variables are text that appears
in between a prefix of "${" and ends with a "}". Some of the interesting
variables include:
// The frame index (0, 1, 2, 3...)
${frame.index}
// common frame registers with generic names
${frame.pc}
${frame.sp}
${frame.fp}
${frame.ra}
${frame.flags}
// Access to any frame registers by name where REGNAME is any register name:
${frame.reg.REGNAME}
// The current compile unit file where the frame is located
${file.basename}
${file.fullpath}
// Function information
${function.name}
${function.pc-offset}
// Process info
${process.file.basename}
${process.file.fullpath}
${process.id}
${process.name}
// Thread info
${thread.id}
${thread.index}
${thread.name}
${thread.queue}
${thread.stop-reason}
// Target information
${target.arch}
// The current module for the current frame (the shared library or executable
// that contains the current frame PC value):
${module.file.basename}
${module.file.fullpath}
// Access to the line entry for where the current frame is when your thread
// is stopped:
${line.file.basename}
${line.file.fullpath}
${line.number}
${line.start-addr}
${line.end-addr}
Many times the information that you might have in your prompt might not be
available and you won't want it to print out if it isn't valid. To take care
of this you can enclose everything that must resolve into a scope. A scope
is starts with '{' and ends with '}'. For example in order to only display
the current file and line number when the information is available the format
would be:
"{ at {$line.file.basename}:${line.number}}"
Broken down this is:
start the scope: "{"
format whose content will only be displayed if all information is available:
"at {$line.file.basename}:${line.number}"
end the scope: "}"
We currently can represent the infomration we see when stopped at a frame:
frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19
with the following format:
"frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n"
This breaks down to always print:
"frame #${frame.index}: ${frame.pc} "
only print the module followed by a tick if we have a valid module:
"{${module.file.basename}`}"
print the function name with optional offset:
"{${function.name}{${function.pc-offset}}"
print the line info if it is available:
"{ at ${line.file.basename}:${line.number}}"
then finish off with a newline:
"\n"
Notice you can also put newlines ("\n") and tabs and everything else you
are used to putting in a format string when desensitized with the \ character.
Cleaned up some of the user settings controller subclasses. All of them
do not have any global settings variables and were all implementing stubs
for the get/set global settings variable. Now there is a default version
in UserSettingsController that will do nothing.
llvm-svn: 114306
Added the ability to specify a preference for mangled or demangled to Mangled::GetName.
Changed one place where mangled was prefered in GetName.
The Dynamic loader should look up the target of a stub by mangled name if it exists.
llvm-svn: 113869
to any inferior process because the code was checking if no run args were
set and then adding and empty string. This was happening for environment
vars as well.
llvm-svn: 113831
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
SBValue to access it. For now this is just the result of ObjC NSPrintForDebugger,
but could be extended. Also store the results of the ObjC Object Printer in a
Stream, not a ConstString.
llvm-svn: 113660
The Unwind and RegisterContext subclasses still need
to be finished; none of this code is used by lldb at
this point (unless you call into it by hand).
The ObjectFile class now has an UnwindTable object.
The UnwindTable object has a series of FuncUnwinders
objects (Function Unwinders) -- one for each function
in that ObjectFile we've backtraced through during this
debug session.
The FuncUnwinders object has a few different UnwindPlans.
UnwindPlans are a generic way of describing how to find
the canonical address of a given function's stack frame
(the CFA idea from DWARF/eh_frame) and how to restore the
caller frame's register values, if they have been saved
by this function.
UnwindPlans are created from different sources. One source is the
eh_frame exception handling information generated by the compiler
for unwinding an exception throw. Another source is an assembly
language inspection class (UnwindAssemblyProfiler, uses the Plugin
architecture) which looks at the instructions in the funciton
prologue and describes the stack movements/register saves that are
done.
Two additional types of UnwindPlans that are worth noting are
the "fast" stack UnwindPlan which is useful for making a first
pass over a thread's stack, determining how many stack frames there
are and retrieving the pc and CFA values for each frame (enough
to create StackFrameIDs). Only a minimal set of registers is
recovered during a fast stack walk.
The final UnwindPlan is an architectural default unwind plan.
These are provided by the ArchDefaultUnwindPlan class (which uses
the plugin architecture). When no symbol/function address range can
be found for a given pc value -- when we have no eh_frame information
and when we don't have a start address so we can't examine the assembly
language instrucitons -- we have to make a best guess about how to
unwind. That's when we use the architectural default UnwindPlan.
On x86_64, this would be to assume that rbp is used as a stack pointer
and we can use that to find the caller's frame pointer and pc value.
It's a last-ditch best guess about how to unwind out of a frame.
There are heuristics about when to use one UnwindPlan versues the other --
this will all happen in the still-begin-written UnwindLLDB subclass of
Unwind which runs the UnwindPlans.
llvm-svn: 113581
to be set up the way they are. Comment out code that removes pending
settings for live instances (after the settings are copied over).
llvm-svn: 113519
pending instance uses the specified instance name rather than creating a new one; add brackets to instance names
when searching for and removing pending instances.
llvm-svn: 113370
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
handles user settable internal variables (the equivalent of set/show
variables in gdb). In addition to the basic infrastructure (most of
which is defined in UserSettingsController.{h,cpp}, there are examples
of two classes that have been set up to contain user settable
variables (the Debugger and Process classes). The 'settings' command
has been modified to be a command-subcommand structure, and the 'set',
'show' and 'append' commands have been moved into this sub-commabnd
structure. The old StateVariable class has been completely replaced
by this, and the state variable dictionary has been removed from the
Command Interpreter. Places that formerly accessed the state variable
mechanism have been modified to access the variables in this new
structure instead (checking the term-width; getting/checking the
prompt; etc.)
Variables are attached to classes; there are two basic "flavors" of
variables that can be set: "global" variables (static/class-wide), and
"instance" variables (one per instance of the class). The whole thing
has been set up so that any global or instance variable can be set at
any time (e.g. on start up, in your .lldbinit file), whether or not
any instances actually exist (there's a whole pending and default
values mechanism to help deal with that).
llvm-svn: 113041
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
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
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
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
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
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
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
functionality into StackFrameList. This will allow us to copy the previous
stack backtrace from the previous stop into another variable so we can re-use
as much as possible from the previous stack backtrace.
llvm-svn: 112007
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
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
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
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
should be hidden behind that, and the "GetStackFrameAtIndex" and "GetStackFrameCount" algorithms become generic. So I moved them to Thread.cpp.
llvm-svn: 110899
expression parser. It is now possible to type:
(lldb) expr int $i = 5; $i + 1
(int) 6
(lldb) expr $i + 2
(int) 7
The skeleton for automatic result variables is
also implemented. The changes affect:
- the process, which now contains a
ClangPersistentVariables object that holds
persistent variables associated with it
- the expression parser, which now uses
the persistent variables during variable
lookup
- TaggedASTType, where I loaded some commonly
used tags into a header so that they are
interchangeable between different clients of
the class
llvm-svn: 110777
stop event is pulled from the event queue. Then made the StopInfoBreakpoint's PerformAction do the
breakpoint command.
Also fixed the StopInfoBreakpoint's GetDescription so it gets the breakpoint location info, not the breakpoint
site info.
llvm-svn: 110637
Arrange that this then gets properly set on attach, or when a "file" is set.
Add a completer for "process attach -n".
Caveats: there isn't currently a way to handle multiple processes with the same name. That
will have to wait on a way to pass annotations along with the completion strings.
llvm-svn: 110624
This will allow debugger plug-ins to make any instance of "lldb_private::StopInfo"
that can completely describe any stop reason. It also provides a framework for
doing intelligent things with the stop info at important times in the lifetime
of the inferior.
Examples include the signal stop info in StopInfoUnixSignal. It will check with
the process to see that the current action is for the signal. These actions
include wether to stop for the signal, wether the notify that the signal was
hit, and wether to pass the signal along to the inferior process. The
StopInfoUnixSignal class overrides the "ShouldStop()" method of StopInfo and
this allows the stop info to determine if it should stop at the signal or
continue the process.
StopInfo subclasses must override the following functions:
virtual lldb::StopReason
GetStopReason () const = 0;
virtual const char *
GetDescription () = 0;
StopInfo subclasses can override the following functions:
// If the subclass returns "false", the inferior will resume. The default
// version of this function returns "true" which means the default stop
// info will stop the process. The breakpoint subclass will check if
// the breakpoint wants us to stop by calling any installed callback on
// the breakpoint, and also checking if the breakpoint is for the current
// thread. Signals will check if they should stop based off of the
// UnixSignal settings in the process.
virtual bool
ShouldStop (Event *event_ptr);
// Sublasses can state if they want to notify the debugger when "ShouldStop"
// returns false. This would be handy for breakpoints where you want to
// log information and continue and is also used by the signal stop info
// to notify that a signal was received (after it checks with the process
// signal settings).
virtual bool
ShouldNotify (Event *event_ptr)
{
return false;
}
// Allow subclasses to do something intelligent right before we resume.
// The signal class will figure out if the signal should be propagated
// to the inferior process and pass that along to the debugger plug-ins.
virtual void
WillResume (lldb::StateType resume_state)
{
// By default, don't do anything
}
The support the Mach exceptions was moved into the lldb/source/Plugins/Process/Utility
folder and now doesn't polute the lldb_private::Thread class with platform
specific code.
llvm-svn: 110184
call Objective-C methods from expressions. Also added
some more logging to the function-calling thread plan
so that we can see the registers when a function
finishes.
Also documented things maybe a bit better.
llvm-svn: 109938
invalidated. There was a race condition where the private thread would
invalidate its own pthread_t object before the parent could perform a
pthread_cancel/pthread_join sequence.
Patch from Stephen Wilson.
llvm-svn: 109131
This relies on ThreadPlanStepOut working correctly, which it doesn't currently for Inlined functions, so this feature is only partially useful until we take care of Stepping Out of inlined functions.
Added an option to "thread step-in" to set the avoid regular expression. This is mostly for testing, once the Setting code is redone, we'll move this to a general setting.
llvm-svn: 108036
enabled LLVM make style building and made this compile LLDB on Mac OS X. We
can now iterate on this to make the build work on both linux and macosx.
llvm-svn: 108009
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
intelligently. The four name types we currently have are:
eFunctionNameTypeFull = (1 << 1), // The function name.
// For C this is the same as just the name of the function
// For C++ this is the demangled version of the mangled name.
// For ObjC this is the full function signature with the + or
// - and the square brackets and the class and selector
eFunctionNameTypeBase = (1 << 2), // The function name only, no namespaces or arguments and no class
// methods or selectors will be searched.
eFunctionNameTypeMethod = (1 << 3), // Find function by method name (C++) with no namespace or arguments
eFunctionNameTypeSelector = (1 << 4) // Find function by selector name (ObjC) names
this allows much more flexibility when setting breakoints:
(lldb) breakpoint set --name main --basename
(lldb) breakpoint set --name main --fullname
(lldb) breakpoint set --name main --method
(lldb) breakpoint set --name main --selector
The default:
(lldb) breakpoint set --name main
will inspect the name "main" and look for any parens, or if the name starts
with "-[" or "+[" and if any are found then a full name search will happen.
Else a basename search will be the default.
Fixed some command option structures so not all options are required when they
shouldn't be.
Cleaned up the breakpoint output summary.
Made the "image lookup --address <addr>" output much more verbose so it shows
all the important symbol context results. Added a GetDescription method to
many of the SymbolContext objects for the more verbose output.
llvm-svn: 107075
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
without having to use RTTI.
Removed the ThreadPlanContinue and replaced with a ShouldAutoContinue query that serves the same purpose. Having to push
another plan to assert that if there's no other indication the target should continue when this plan is popped was flakey
and error prone. This method is more stable, and fixed problems we were having with thread specific breakpoints.
llvm-svn: 106378
than picking bits out of the breakpoint options. Added BreakpointOptions::GetDescription to do this job. Some more mucking
around to keep the breakpoint listing from getting too verbose.
llvm-svn: 106262
Push this through all the breakpoint management code. Allow this to be set when the breakpoint is created.
Fix the Process classes so that a breakpoint hit that is not for a particular thread is not reported as a
breakpoint hit event for that thread.
Added a "breakpoint configure" command to allow you to reset any of the thread
specific options (or the ignore count.)
llvm-svn: 106078
Caroline Tice