History log of /external/lldb/source/Target/StackFrame.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
52f792329be5db8e38961350589e97e8f2823acd 12-Jul-2013 Greg Clayton <gclayton@apple.com> Huge change to clean up types.

A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error.

This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@186130 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
17d5a0358d60922707fdab6ec9c3251ca44dd614 23-May-2013 Michael Sartain <mikesart@valvesoftware.com> Add ${ansi.XX} parsing to lldb prompt, use-color setting, and -no-use-colors command line options.
settings set use-color [false|true]
settings set prompt "${ansi.bold}${ansi.fg.green}(lldb)${ansi.normal} "
also "--no-use-colors" on the command prompt



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@182609 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
2154a4153c0c85d10f9c57d8870a376326cb6c6a 29-Apr-2013 Jason Molenda <jmolenda@apple.com> When lldb stops in a stack frame where we have source level information (file, line number), don't
print the disassembly context around $pc -- just print the filename and line number, even if we
can't show the source code. Previously if the source file was not available, lldb would print
the source filename & line number and assembly.
<rdar://problem/13072951>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@180706 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
7d4083837c5a258375fdc185d464b4ed15759a4b 02-Mar-2013 Jim Ingham <jingham@apple.com> Convert from the C-based LLVM Disassembler shim to the full MC Disassembler API's.
Calculate "can branch" using the MC API's rather than our hand-rolled regex'es.
As extra credit, allow setting the disassembly flavor for x86 based architectures to intel or att.

<rdar://problem/11319574>
<rdar://problem/9329275>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@176392 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
744dd7909a7cbe1158ec8af6e3293cf033ccc638 26-Feb-2013 Greg Clayton <gclayton@apple.com> Backed out a hacky fix that is no longer needed.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@176106 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
a7e864cb0a450c7ef65b6f9f6c9bae839c405906 23-Feb-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13265297>

StackFrame assumes m_sc is additive, but m_sc can lose its target. So now the SymbolContext::Clear() method takes a bool that indicates if the target should be cleared. Modified all existing code to properly set the bool argument.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@175953 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
8ea48780aad5d1cc43fd12ef0f42ab8ac2f196b9 21-Feb-2013 Sean Callanan <scallanan@apple.com> Fixed a case where a stack frame could lose track
of its own target.

<rdar://problem/13121412>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@175794 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
b912457e1eb6f97d3ee3adc74d1e0f6393e35d3c 06-Dec-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/12560257>

Fixed zero sized arrays to work correctly. This will only happen once we get a clang that emits correct debug info for zero sized arrays. For now I have marked the TestStructTypes.py as an expected failure.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@169465 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
d891f9b872103235cfd2ed452c6f14a4394d9b3a 05-Dec-2012 Daniel Malea <daniel.malea@intel.com> Fix Linux build warnings due to redefinition of macros:
- 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!




git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@169341 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
5f35a4be95aed0e5b2cb36f7d785bcbfc67284ae 29-Nov-2012 Daniel Malea <daniel.malea@intel.com> Resolve printf formatting warnings on Linux:
- use macros from inttypes.h for format strings instead of OS-specific types

Patch from Matt Kopec!



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@168945 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
214d2a327feb2e5987d093c2b63c457ffbd1d677 29-Nov-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/12445557>

Make stack frames fix up their line table entries when the target has source remappings. Also rearranged how the m_sc.target_sp was filled in so it can be used during the StackFrame::GetSymbolContext(...) function.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@168845 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
0c8fa2d7dd18ae1816c82846234c45f79142e3df 01-Sep-2012 Jim Ingham <jingham@apple.com> Initial check-in of "fancy" inlined stepping. Doesn't do anything useful unless you switch LLDB_FANCY_INLINED_STEPPING to true. With that
on, basic inlined stepping works, including step-over of inlined functions. But for some as yet mysterious reason i386 debugging gets an
assert and dies immediately. So for now its off.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@163044 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
49ce8969d3154e1560106cfe530444c09410f217 29-Aug-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11757916>

Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file".
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()

Cleaned up header includes a bit as well.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162860 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
73844aa19a7360b662e2be710fc3c969d6c86606 22-Aug-2012 Greg Clayton <gclayton@apple.com> Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation:
- no setting auto completion
- very manual and error prone way of getting/setting variables
- tons of code duplication
- useless instance names for processes, threads

Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing".



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162366 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
b3a1a2bba41281ba56a99fe64887a8a04760784c 14-Jul-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11870357>

Allow "frame variable" to find ivars without the need for "this->" or "self->".


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@160211 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
a7d3dc75ec4f46033c3f991f11fb58a058091a85 11-Jul-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11852100>

The "stop-line-count-after" and "stop-line-count-before" settings are broken. This fixes them.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@160071 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
cf09f885c201becf51acc4a5cfac00b3df53f2a8 19-Mar-2012 Enrico Granata <egranata@apple.com> Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern
Changes to synthetic children:
- the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points
this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed
- making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly)
claim to itself be synthetic
- cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible
- major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself
- removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place)
Some clean ups to the summary generation code
Centralized the code that clears out user-visible strings and data in ValueObject
More efficient summaries for libc++ containers


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@153061 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
6e12c7a5a851f661677b16c544aac2f93fb6e86d 08-Mar-2012 Sean Callanan <scallanan@apple.com> Updated the revision of LLVM/Clang used by LLDB.
This takes two important changes:

- Calling blocks is now supported. You need to
cast their return values, but that works fine.

- We now can correctly run JIT-compiled
expressions that use floating-point numbers.

Also, we have taken a fix that allows us to
ignore access control in Objective-C as in C++.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@152286 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
3508c387c3f0c9ecc439d98048fd7694d41bab1b 24-Feb-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/10103468>

I started work on being able to add symbol files after a debug session
had started with a new "target symfile add" command and quickly ran into
problems with stale Address objects in breakpoint locations that had
lldb_private::Section pointers into modules that had been removed or
replaced. This also let to grabbing stale modules from those sections.
So I needed to thread harded the Address, Section and related objects.

To do this I modified the ModuleChild class to now require a ModuleSP
on initialization so that a weak reference can created. I also changed
all places that were handing out "Section *" to have them hand out SectionSP.
All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild
so all of the find plug-in, static creation function and constructors now
require ModuleSP references instead of Module *.

Address objects now have weak references to their sections which can
safely go stale when a module gets destructed.

This checkin doesn't complete the "target symfile add" command, but it
does get us a lot clioser to being able to do such things without a high
risk of crashing or memory corruption.




git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151336 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
f4124deeb9532044a38c0774ced872f2709347da 21-Feb-2012 Greg Clayton <gclayton@apple.com> Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr
objects for the backlink to the lldb_private::Process. The issues we were
running into before was someone was holding onto a shared pointer to a
lldb_private::Thread for too long, and the lldb_private::Process parent object
would get destroyed and the lldb_private::Thread had a "Process &m_process"
member which would just treat whatever memory that used to be a Process as a
valid Process. This was mostly happening for lldb_private::StackFrame objects
that had a member like "Thread &m_thread". So this completes the internal
strong/weak changes.

Documented the ExecutionContext and ExecutionContextRef classes so that our
LLDB developers can understand when and where to use ExecutionContext and
ExecutionContextRef objects.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151009 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
289afcb5e26c2527a0d2e71f84e780b86bbcf90a 18-Feb-2012 Greg Clayton <gclayton@apple.com> The second part in thread hardening the internals of LLDB where we make
the lldb_private::StackFrame objects hold onto a weak pointer to the thread
object. The lldb_private::StackFrame objects the the most volatile objects
we have as when we are doing single stepping, frames can often get lost or
thrown away, only to be re-created as another object that still refers to the
same frame. We have another bug tracking that. But we need to be able to
have frames no longer be able to get the thread when they are not part of
a thread anymore, and this is the first step (this fix makes that possible
but doesn't implement it yet).

Also changed lldb_private::ExecutionContextScope to return shared pointers to
all objects in the execution context to further thread harden the internals.




git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@150871 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
13d24fb1817faa7ccc4cfd799113ba1a2b8968eb 29-Jan-2012 Greg Clayton <gclayton@apple.com> Switching back to using std::tr1::shared_ptr. We originally switched away
due to RTTI worries since llvm and clang don't use RTTI, but I was able to
switch back with no issues as far as I can tell. Once the RTTI issue wasn't
an issue, we were looking for a way to properly track weak pointers to objects
to solve some of the threading issues we have been running into which naturally
led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared
pointer from just a pointer, which is also easily solved using the
std::tr1::enable_shared_from_this class.

The main reason for this move back is so we can start properly having weak
references to objects. Currently a lldb_private::Thread class has a refrence
to its parent lldb_private::Process. This doesn't work well when we now hand
out a SBThread object that contains a shared pointer to a lldb_private::Thread
as this SBThread can be held onto by external clients and if they end up
using one of these objects we can easily crash.

So the next task is to start adopting std::tr1::weak_ptr where ever it makes
sense which we can do with lldb_private::Debugger, lldb_private::Target,
lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and
many more objects now that they are no longer using intrusive ref counted
pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive
pointers).



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@149207 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
be9875dc16a839be592110d9de6dc2c9285c5b61 21-Nov-2011 Greg Clayton <gclayton@apple.com> Many GDB users always want to display disassembly when they stop by using
something like "display/4i $pc" (or something like this). With LLDB we already
were showing 3 lines of source before and 3 lines of source after the current
source line when showing a stop context. We now improve this by allowing the
user to control the number of lines with the new "stop-line-count-before" and
"stop-line-count-after" settings. Also, there is a new setting for how many
disassembly lines to show: "stop-disassembly-count". This will control how many
source lines are shown when there is no source or when we have no source line
info.

settings set stop-line-count-before 3
settings set stop-line-count-after 3
settings set stop-disassembly-count 4
settings set stop-disassembly-display no-source

The default values are set as shown above and allow 3 lines of source before
and after (what we used to do) the current stop location, and will display 4
lines of disassembly if the source is not available or if we have no debug
info. If both "stop-source-context-before" and "stop-source-context-after" are
set to zero, this will disable showing any source when stopped. The
"stop-disassembly-display" setting is an enumeration that allows you to control
when to display disassembly. It has 3 possible values:

"never" - never show disassembly no matter what
"no-source" - only show disassembly when there is no source line info or the source files are missing
"always" - always show disassembly.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@145050 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
23b8abbe214c252028f6e09f79169529c846409d 26-Sep-2011 Greg Clayton <gclayton@apple.com> Added more functionality to the public API to allow for better
symbolication. Also improved the SBInstruction API to allow
access to the instruction opcode name, mnemonics, comment and
instruction data.

Added the ability to edit SBLineEntry objects (change the file,
line and column), and also allow SBSymbolContext objects to be
modified (set module, comp unit, function, block, line entry
or symbol).

The SymbolContext and SBSymbolContext can now generate inlined
call stack infomration for symbolication much easier using the
SymbolContext::GetParentInlinedFrameInfo(...) and
SBSymbolContext::GetParentInlinedFrameInfo(...) methods.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@140518 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
567e7f3ba16eb48cb9fd6a2f26f2f7269eb6983c 22-Sep-2011 Greg Clayton <gclayton@apple.com> Converted the lldb_private::Process over to use the intrusive
shared pointers.

Changed the ExecutionContext over to use shared pointers for
the target, process, thread and frame since these objects can
easily go away at any time and any object that was holding onto
an ExecutionContext was running the risk of using a bad object.

Now that the shared pointers for target, process, thread and
frame are just a single pointer (they all use the instrusive
shared pointers) the execution context is much safer and still
the same size.

Made the shared pointers in the the ExecutionContext class protected
and made accessors for all of the various ways to get at the pointers,
references, and shared pointers.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@140298 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
95b7b4362ca7135be088e4fbf04c2bd15767a104 20-Sep-2011 Jason Molenda <jmolenda@apple.com> Change Error::SetErrorStringWithFormat() prototype to use an
__attribute__ format so the compiler knows that this method takes
printf style formatter arguments and checks that it's being used
correctly. Fix a couple dozen incorrect SetErrorStringWithFormat()
calls throughout the sources.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@140115 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
987c7ebe1daa425ba7abfa9643800e3237146fc0 17-Sep-2011 Greg Clayton <gclayton@apple.com> Adopt the intrusive pointers in:

lldb_private::Breakpoint
lldb_private::BreakpointLocations
lldb_private::BreakpointSite
lldb_private::Debugger
lldb_private::StackFrame
lldb_private::Thread
lldb_private::Target



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@139985 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
02e210cad27e36108bef493b798c2c1eb3b04cb8 17-Sep-2011 Greg Clayton <gclayton@apple.com> Removed the function:

ModuleSP
Module::GetSP();

Since we are now using intrusive ref counts, we can easily turn any
pointer to a module into a shared pointer just by assigning it.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@139984 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
fdf24efe672bf3fa041cdbebd2d7f406b11882bd 09-Sep-2011 Jim Ingham <jingham@apple.com> Move the SourceManager from the Debugger to the Target. That way it can store the per-Target default Source File & Line.
Set the default Source File & line to main (if it can be found.) at startup. Selecting the current thread & or frame resets
the current source file & line, and "source list" as well as the breakpoint command "break set -l <NUM>" will use the
current source file.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@139323 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
13a54a141acd6255e4e11db466951ec1f26aa2f5 19-Aug-2011 Enrico Granata <granata.enrico@gmail.com> Taking care of an issue with using lldb_private types in SBCommandInterpreter.cpp ; Making NSString test case work on Snow Leopard ; Removing an unused variable warning

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@138105 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
6f30287bdc836c715fcac75b06ec58d13b79e715 19-Aug-2011 Enrico Granata <granata.enrico@gmail.com> - Now using ${var} as the summary for an aggregate type will produce "name-of-type @ object-location" instead of giving an error
e.g. you may get "foo_class @ 0x123456" when typing "type summary add -f ${var} foo_class"
- Added a new special formatting token %T for summaries. This shows the type of the object.
Using it, the new "type @ location" summary could be manually generated by writing ${var%T} @ ${var%L}
- Bits and pieces required to support "frame variable array[n-m]"
The feature is not enabled yet because some additional design and support code is required, but the basics
are getting there
- Fixed a potential issue where a ValueObjectSyntheticFilter was not holding on to its SyntheticChildrenSP
Because of the way VOSF are being built now, this has never been an actual issue, but it is still sensible for
a VOSF to hold on to the SyntheticChildrenSP as well as to its FrontEnd


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@138080 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
9c57fc067307ebb1abe50de6ff704d4b2ae9b9d4 11-Aug-2011 Enrico Granata <granata.enrico@gmail.com> Fixed an issue where a pointer's address was being logged instead of its value
Access to synthetic children by name:
if your object has a synthetic child named foo you can now type
frame variable object.foo (or ->foo if you have a pointer)
and that will print the value of the synthetic child
(if your object has an actual child named foo, the actual child prevails!)
this behavior should also work in summaries, and you should be able to use
${var.foo} and ${svar.foo} interchangeably
(but using svar.foo will mask an actual child named foo)


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@137314 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
f669850b51f3898020cbae8fdfd17faf4f18ba02 09-Aug-2011 Enrico Granata <granata.enrico@gmail.com> Basic support for reading synthetic children by index:
if your datatype provides synthetic children, "frame variable object[index]" should now do the right thing
in cases where the above syntax would have been rejected before, i.e.
object is not a pointer nor an array (frame variable ignores potential overload of [])
object is a pointer to an Objective-C class (which cannot be dereferenced)
expression will still run operator[] if available and complain if it cannot do so
synthetic children by name do not work yet


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@137097 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
6e2d2823b1bfa4e6a57996391696ba25a2dd069b 03-Aug-2011 Greg Clayton <gclayton@apple.com> Fixed an issue where StackFrame::GetValueForVariableExpressionPath(...)
was previously using the entire frame variable list instead of using the
in scope variable list. I added a new function to a stack frame:

lldb::VariableListSP
StackFrame::GetInScopeVariableList (bool get_file_globals);

This gets only variables that are in scope and they will be ordered such
that the variables from the current scope are first.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@136745 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
4c3fb4b50a87e6e08987096d7edacc26545f58dc 19-Jul-2011 Enrico Granata <granata.enrico@gmail.com> The implementation of categories is now synchronization safe
Code cleanup:
- The Format Manager implementation is now split between two files: FormatClasses.{h|cpp} where the
actual formatter classes (ValueFormat, SummaryFormat, ...) are implemented and
FormatManager.{h|cpp} where the infrastructure classes (FormatNavigator, FormatManager, ...)
are contained. The wrapper code always remains in Debugger.{h|cpp}
- Several leftover fields, methods and comments from previous design choices have been removed
type category subcommands (enable, disable, delete) now can take a list of category names as input
- for type category enable, saying "enable A B C" is the same as saying
enable C
enable B
enable A
(the ordering is relevant in enabling categories, and it is expected that a user typing
enable A B C wants to look into category A, then into B, then into C and not the other
way round)
- for the other two commands, the order is not really relevant (however, the same inverted ordering
is used for consistency)


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@135494 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
107e53da8bdca540db8b734ed237688eaeee85c5 06-Jul-2011 Greg Clayton <gclayton@apple.com> Fixed some issues with ARM backtraces by not processing any push/pop
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.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@134461 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
9762e10787a7efc2f0d822590cab42ca23d5e4f9 06-Jul-2011 Enrico Granata <granata.enrico@gmail.com> new syntax for summary strings:
- ${*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

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@134458 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
4bb0f19c87ee5d3d3ee3cfa6402564587f72dd37 22-Jun-2011 Greg Clayton <gclayton@apple.com> Fixed an issue where SBFrame::GetDisassembly() was returning disassembly that
contained the current line marker. This is now an option which is not enabled
for the API disassembly call.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@133597 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
1bd2b2feb7694e06b9a971063c283f9c490479d2 18-Jun-2011 Greg Clayton <gclayton@apple.com> Fixed variable parsing to not parse block variables over and over due to an
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@133302 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
10de7d1db3ec782ea2ccda1f39c0a40b9c301594 04-May-2011 Jim Ingham <jingham@apple.com> Change "frame var" over to using OptionGroups (and thus the OptionGroupVariableObjectDisplay).
Change the boolean "use_dynamic" over to a tri-state, no-dynamic, dynamic-w/o running target,
and dynamic with running target.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@130832 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
ff44ab42e9f5d8e4d550e11d1b69413e0bc75b71 23-Apr-2011 Greg Clayton <gclayton@apple.com> Fixed the SymbolContext::DumpStopContext() to correctly indent and dump
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.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@130044 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
47da810225d8674eb9158bcf5f1f5b847cbaeedf 23-Apr-2011 Jim Ingham <jingham@apple.com> Fix up how the ValueObjects manage their life cycle so that you can hand out 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.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@130035 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
abe0fed36d83e1c37af9dae90c2d25db742b4515 18-Apr-2011 Greg Clayton <gclayton@apple.com> Centralized a lot of the status information for processes,
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.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@129695 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
e41494a9092e15192012a5e0a8a1ffd66c70b8bb 16-Apr-2011 Jim Ingham <jingham@apple.com> Add support for "dynamic values" for C++ classes. This currently only works 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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@129623 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
fa3a16a2ea380ef38388ebe323817bd1b32c20cd 31-Mar-2011 Jim Ingham <jingham@apple.com> Convert ValueObject to explicitly maintain the Execution Context in which 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.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@128593 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
149731c0b267e5b6cd7192cbfac0c7f457ae5cfc 25-Mar-2011 Greg Clayton <gclayton@apple.com> Cleaned up the Disassembler code a bit more. You can now request a disassembler
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.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@128290 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
aa3e3e1f0f3be95c79f902c5331e11878f66b365 22-Mar-2011 Jim Ingham <jingham@apple.com> Add the ability to disassemble "n" instructions from the current PC, or the first "n" instructions in a function.
Also added a "-p" flag that disassembles from the current pc.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@128063 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
a846cc3c9e57124838fed9793e7fd4610b8da9d7 11-Mar-2011 Sean Callanan <scallanan@apple.com> Fixed the -r parameter to the disassemble command
so that it actually triggers raw output.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@127433 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
395fc33dc4b06c048ed35047ec461bc092ef2df3 15-Feb-2011 Greg Clayton <gclayton@apple.com> Made lldb_private::ArchSpec contain much more than just an architecture. It
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.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@125602 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
bdcb6abaa287df2c5f312c51d993c1d0b0cb120c 26-Jan-2011 Greg Clayton <gclayton@apple.com> Enabled extra warnings and fixed a bunch of small issues.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@124250 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
c67efa41a83b0f8b2bab467436a23b50a44e7f30 20-Jan-2011 Greg Clayton <gclayton@apple.com> Added the ability to StackFrame::GetValueForVariableExpressionPath(...) to avoid
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@123938 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
b01000fd063629facd45044f137446fb748ee179 17-Jan-2011 Greg Clayton <gclayton@apple.com> A few of the issue I have been trying to track down and fix have been due to
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@123613 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
08d7d3ae16110aa68ed40c161eac8571aeb94cd9 06-Jan-2011 Greg Clayton <gclayton@apple.com> Fixed issues with RegisterContext classes and the subclasses. There was
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@122976 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
bdcda468276dc9ab6bf648fc8cc07f3faad91526 20-Dec-2010 Greg Clayton <gclayton@apple.com> The LLDB API (lldb::SB*) is now thread safe!



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@122262 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
c3b61d239a53271d013b82ffaba6ab4e92b7fcc1 15-Dec-2010 Greg Clayton <gclayton@apple.com> Fixed the "expression" command object to use the 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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@121841 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
427f290ff96f3ab9f2cf3a1af7001d2c560424c7 14-Dec-2010 Greg Clayton <gclayton@apple.com> Modified LLDB expressions to not have to JIT and run code just to see variable
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@121745 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
8e69de4b9c55ec2eaebc62e4d987c2f0618ac431 20-Nov-2010 Jason Molenda <jmolenda@apple.com> Change the DWARFExpression::Evaluate methods to take an optional
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@119885 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
89363592676e0805f7637dc81ec68a0f100e1683 01-Nov-2010 Sean Callanan <scallanan@apple.com> Fixed StackFrame::GetVariableList to add global
variables to the list of found variables if they
have not yet been added.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@117896 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
f3d0b0c8081691128626eb496fdfcbf8ae54c1de 27-Oct-2010 Greg Clayton <gclayton@apple.com> Updated the lldb_private::Flags class to have better method names and made
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@117437 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
a830adbcd63d1995a01e6e18da79893c1426ca43 04-Oct-2010 Greg Clayton <gclayton@apple.com> There are now to new "settings set" variables that live in each debugger
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.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@115485 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
ccd584dccb920cdb028de69950774c3bcdc025ec 23-Sep-2010 Jim Ingham <jingham@apple.com> Add GetSP to the StackFrame.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@114674 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
eea264007bc5fb42c8f3239726a9d28ae42e1b7b 15-Sep-2010 Greg Clayton <gclayton@apple.com> Moved the section load list up into the target so we can use the target
to symbolicate things without the need for a valid process subclass.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@113895 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
178710cd4307f3d44dc76ebd70fc7daf7ebe17c5 14-Sep-2010 Greg Clayton <gclayton@apple.com> Looking at some of the test suite failures in DWARF in .o files with the
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".



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@113829 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
e2c5e45247a31c3ebd685e9f0511a02ed9b2b067 13-Sep-2010 Greg Clayton <gclayton@apple.com> Fixed an assertion that happened when debugging DWARF in .o files with debug
map on macosx.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@113737 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
69aa5d9a7620a183cdc4da12cc87ea82e2ffcbf9 07-Sep-2010 Greg Clayton <gclayton@apple.com> Added more API to lldb::SBBlock to allow getting the block
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@113195 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
5205f0b6585a127acc6ed210021abb6091220a89 03-Sep-2010 Greg Clayton <gclayton@apple.com> Fixed the StackFrame to correctly resolve the StackID's SymbolContextScope.

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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@112973 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
72b7158235500ae6d4b69ed378cbc36bf6e5cbe1 02-Sep-2010 Greg Clayton <gclayton@apple.com> Added a new bool parameter to many of the DumpStopContext() methods that
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@112867 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
17dae081d7b88d24a7af6b07c10fc5981f81e2a9 02-Sep-2010 Greg Clayton <gclayton@apple.com> StackFrame objects now own ValueObjects for any frame variables (locals, args,
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@112800 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
4fb08150367853dae24bb92904356788e919a72f 30-Aug-2010 Greg Clayton <gclayton@apple.com> Clarified the intent of the SymbolContextScope class in the header
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@112495 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
870a1cdb923ce708d474af357dd1fea3d063ab97 27-Aug-2010 Greg Clayton <gclayton@apple.com> Made it so we update the current frames from the previous frames by doing STL
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@112301 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
1d66ef5d31a8326d5495f56b0cfbf2fd1bff67d8 27-Aug-2010 Greg Clayton <gclayton@apple.com> Simplified the StackFrameList class down to a single frames list again
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@112277 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
65124eac53b7a214906e8931be314e429bbbeb30 27-Aug-2010 Greg Clayton <gclayton@apple.com> Changed the StackID to store its start PC address as a load address instead of
a section offset address.

Fixed up some very inefficient STL code.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@112230 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
2154da49d2db0b478d54c077d2b3825380a24f4c 26-Aug-2010 Jim Ingham <jingham@apple.com> Add StackFrame::IsInlined.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@112217 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
f40e30823926f27e3cb9364f3c8fe2e4be0c7658 26-Aug-2010 Greg Clayton <gclayton@apple.com> Cleaned up the inline stack frame code one more time to prepare for inlined
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@112152 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
32f4fdde0882395aec2ea56d1adcce78759105b7 25-Aug-2010 Greg Clayton <gclayton@apple.com> Fixed another issue with the inline stack frames where if the first frame
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@111989 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
b04e7a805310f2f2cc77947a8b263de9061617ae 24-Aug-2010 Greg Clayton <gclayton@apple.com> Got a lot of the kinks worked out in the inline support after debugging more
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).



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@111964 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
33ed170599d41fe407a4dcf5f0875c75e1ad1375 24-Aug-2010 Greg Clayton <gclayton@apple.com> Added support for inlined stack frames being represented as real stack frames
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.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@111877 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
75ccf50c3371d8c8e293af25461705b86fb10a46 21-Aug-2010 Greg Clayton <gclayton@apple.com> Modified the host process monitor callback function 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.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@111706 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
704363531ee4877ccc6d35d0702876096f54c67b 01-Jul-2010 Greg Clayton <gclayton@apple.com> Centralized all disassembly into static functions in 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.





git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@107350 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
63094e0bb161580564954dee512955c1c79d3476 23-Jun-2010 Greg Clayton <gclayton@apple.com> Very large changes that were needed in order to allow multiple connections
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@106615 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp
24943d2ee8bfaa7cf5893e4709143924157a5c1e 08-Jun-2010 Chris Lattner <sabre@nondot.org> Initial checkin of lldb code from internal Apple repo.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@105619 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/StackFrame.cpp