History log of /external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.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/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
0e191607adcb0ea8ebd06c278be648a7f5c0097f 10-May-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13854277>
<rdar://problem/13594769>

Main changes in this patch include:
- cleanup plug-in interface and use ConstStrings for plug-in names
- Modfiied the BSD Archive plug-in to be able to pick out the correct .o file when .a files contain multiple .o files with the same name by using the timestamp
- Modified SymbolFileDWARFDebugMap to properly verify the timestamp on .o files it loads to ensure we don't load updated .o files and cause problems when debugging

The plug-in interface changes:

Modified the lldb_private::PluginInterface class that all plug-ins inherit from:

Changed:

virtual const char * GetPluginName() = 0;

To:

virtual ConstString GetPluginName() = 0;

Removed:

virtual const char * GetShortPluginName() = 0;

- Fixed up all plug-in to adhere to the new interface and to return lldb_private::ConstString values for the plug-in names.
- Fixed all plug-ins to return simple names with no prefixes. Some plug-ins had prefixes and most ones didn't, so now they all don't have prefixed names, just simple names like "linux", "gdb-remote", etc.






git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@181631 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
36da2aa6dc5ad9994b638ed09eb81c44cc05540b 25-Jan-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13069948>

Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.

So I defined a new "lldb::offset_t" which should be used for all file offsets.

After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.

Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@173463 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
d35b7b3bfd21f4fd6b048693563eef1b772ae197 07-Dec-2012 Daniel Malea <daniel.malea@intel.com> More Linux warnings fixes (remove default labels as needed):
- as per http://llvm.org/docs/CodingStandards.html#don-t-use-default-labels-in-fully-covered-switches-over-enumerations

Patch by Matt Kopec!




git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@169633 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
70a8945707e775bf50ffe442fee1155d96d599f1 06-Dec-2012 Jason Molenda <jmolenda@apple.com> Fix ABIMacOSX_i386::RegisterIsVolatile to return the negated value of
RegisterIsCalleeSaved. Add ebp back to the list of registers that
are callee saved.
<rdar://problem/12817918>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@169466 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
dd06f93a62e84c046344817621079582e159a802 05-Dec-2012 Greg Clayton <gclayton@apple.com> Backed out part of the ABI changes that were checked in because it breaks the i386 test suite as it makes backtraces for the first instruction of a function fail. Stepping relies on backtraces being correct, so I am reverting what is causing the breakage.

I filed this to track the fix:

<rdar://problem/12817918> Recent i386 ABI changes break the i386 test suite because stack backtracing is busted when stopped in trampolines




git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@169409 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
bdf98efd294124809e463fa2bcfbd5a453aef60f 04-Dec-2012 Jason Molenda <jmolenda@apple.com> Fix comment in ABIMacOSX_i386::RegisterIsCalleeSaved to say that
these are the *non-volatile* registers on Darwin/i386, not the
volatile registers.
Recognize the sp, pc, fp generic reg names as well.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@169316 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
37816a3429a075e19b74f64fd642d5a5d7ec6f2f 26-Oct-2012 Jason Molenda <jmolenda@apple.com> Add a new capability to RegisterContextLLDB: To recognize when the
Full UnwindPlan is trying to do an impossible unwind; in that case
invalidate the Full UnwindPlan and replace it with the architecture
default unwind plan.

This is a scenario that happens occasionally with arm unwinds in
particular; the instruction analysis based full unwindplan can
mis-parse the functions and the stack walk stops prematurely. Now
we can do a simpleminded frame-chain walk to find the caller frame
and continue the unwind. It's not ideal but given the complicated
nature of analyzing the arm functions, and the lack of eh_frame
information on iOS, it is a distinct improvement and fixes some
long-standing problems with the unwinder on that platform.

This is fixing <rdar://problem/12091421>. I may re-use this
invalidate feature in the future if I can identify other cases where
the full unwindplan's unwind information is clearly incorrect.

This checkin also includes some cleanup for the volatile register
definition in the arm ABI plugin for <rdar://problem/10652166>
although work remains to be done for that bug.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@166757 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
d67fa46c289be86383bfa4dd2083ffd7c948ddc7 05-Oct-2012 Sean Callanan <scallanan@apple.com> Made the i386 ABI mark EBP as non-volatile,
because the unwinders typically can find its
value.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@165266 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
466574555e98bc093d443d88492ce9db6ef3015f 27-Sep-2012 Jim Ingham <jingham@apple.com> Implement returning integer values in "thread return" for arm, x86_64 and i386. Also returns
floats & doubles on x86_64.

<rdar://problem/8356523>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@164741 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
0ea775391bd3433dfcc1788bb6ac5f0e5c01e8ad 25-Sep-2012 Jason Molenda <jmolenda@apple.com> Fix string comparisons in ABIMacOSX_i386::RegisterIsCalleeSaved so
that volatile registers are correctly reported for this ABI.
We were incorrectly passing up volatile registers from callee
frames.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@164564 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
a17a81a1a9ff6b8d87c4a1e47dd874f6ea8a4f1d 12-Sep-2012 Jim Ingham <jingham@apple.com> Start at getting "thread return" working. Doesn't work yet.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@163670 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
68fa4ec4361d1ea5a78a8a7eba2b8015e3dd68f7 14-Jul-2012 Jason Molenda <jmolenda@apple.com> Switch nearly all of the use of the UnwindPlan::Row's to go through
a shared pointer to ease some memory management issues with a patch
I'm working on.

The main complication with using SPs for these objects is that most
methods that build up an UnwindPlan will construct a Row to a given
instruction point in a function, then add additional regsaves in
the next instruction point to that row and push it again. A little
care is needed to not mutate the previous instruction point's Row
once these are switched to being held behing shared pointers.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@160214 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
7fad24a9fd7226016b28fef78930501a1bef898c 09-Jul-2012 Jason Molenda <jmolenda@apple.com> Simplify the CreateDefaultUnwindPlan methods for the x86 and arm unwinders
a bit -- we're creating the UnwindPlan here, we can set the register set to
whatever is convenient for us, no need to handle different register sets.

A handful of small comment fixes I noticed while reading through the code.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@159924 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
1ab86f7af6935b3346d1280f0eb9857375423b78 07-Jul-2012 Sean Callanan <scallanan@apple.com> On i386 we see occasional crashes when the register
context is not returning valid registers yet. Don't
crash in these situations.

<rdar://problem/11650335>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@159885 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
402607fe513617c06282d4ae479522e244a53b71 29-Feb-2012 Johnny Chen <johnny.chen@apple.com> rdar://problem/10652076

Initial step -- infrastructure change -- to fix the bug. Change the RegisterInfo data structure
to contain two additional fields (uint32_t *value_rges and uint32_t *invalidate_regs) to facilitate
architectures which have register mapping.

Update all existing RegsiterInfo arrays to have two extra NULL's (the additional fields) in each row,
GDBRemoteRegisterContext.cpp is modified to add d0-d15 and q0-q15 register info entries which take
advantage of the value_regs field to specify the containment relationship:

d0 -> (s0, s1)
...
d15 -> (s30, s31)
q0 -> (d0, d1)
...
q15 -> (d30, d31)


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151686 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.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/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
016ef8886cd429f8a53bff967e601f831e409eaa 22-Dec-2011 Jim Ingham <jingham@apple.com> Improve the x86_64 return value decoder to handle most structure returns.
Switch from GetReturnValue, which was hardly ever used, to GetReturnValueObject
which is much more convenient.
Return the "return value object" as a persistent variable if requested.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@147157 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
819dd5e0990e8550d0185f65cc5cf4bc3d9d1058 15-Sep-2011 Jason Molenda <jmolenda@apple.com> Have the FuncUnwinder object request & provide an architecture-defined
UnwindPlan for unwinding from the first instruction of an otherwise
unknown function call (GetUnwindPlanArchitectureDefaultAtFunctionEntry()).

Update RegisterContextLLDB::GetFullUnwindPlanForFrame() to detect the
case of a frame 0 at address 0x0 which indicates that we jumped through
a NULL function pointer. Use the ABI's FunctionEntryUnwindPlan to
find the caller frame.

These changes make it so lldb can identify the calling frame correctly
in code like

int main ()
{
void (*f)(void) = 0;
f();
}




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@139760 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
37f962e785be99dc4f0c5e9d02416992ff03bbd0 22-Aug-2011 Greg Clayton <gclayton@apple.com> Added a new plug-in type: lldb_private::OperatingSystem. The operating system
plug-ins are add on plug-ins for the lldb_private::Process class that can add
thread contexts that are read from memory. It is common in kernels to have
a lot of threads that are not currently executing on any cores (JTAG debugging
also follows this sort of thing) and are context switched out whose state is
stored in memory data structures. Clients can now subclass the OperatingSystem
plug-ins and then make sure their Create functions correcltly only enable
themselves when the right binary/target triple are being debugged. The
operating system plug-ins get a chance to attach themselves to processes just
after launching or attaching and are given a lldb_private::Process object
pointer which can be inspected to see if the main executable, target triple,
or any shared libraries match a case where the OS plug-in should be used.
Currently the OS plug-ins can create new threads, define the register contexts
for these threads (which can all be different if desired), and populate and
manage the thread info (stop reason, registers in the register context) as
the debug session goes on.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@138228 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
c0fa53324d62a48257c092a3347d6e7236aa3152 23-May-2011 Greg Clayton <gclayton@apple.com> Added new lldb_private::Process memory read/write functions to stop a bunch
of duplicated code from appearing all over LLDB:

lldb::addr_t
Process::ReadPointerFromMemory (lldb::addr_t vm_addr, Error &error);

bool
Process::WritePointerToMemory (lldb::addr_t vm_addr, lldb::addr_t ptr_value, Error &error);

size_t
Process::ReadScalarIntegerFromMemory (lldb::addr_t addr, uint32_t byte_size, bool is_signed, Scalar &scalar, Error &error);

size_t
Process::WriteScalarToMemory (lldb::addr_t vm_addr, const Scalar &scalar, uint32_t size, Error &error);

in lldb_private::Process the following functions were renamed:

From:
uint64_t
Process::ReadUnsignedInteger (lldb::addr_t load_addr,
size_t byte_size,
Error &error);

To:
uint64_t
Process::ReadUnsignedIntegerFromMemory (lldb::addr_t load_addr,
size_t byte_size,
uint64_t fail_value,
Error &error);

Cleaned up a lot of code that was manually doing what the above functions do
to use the functions listed above.

Added the ability to get a scalar value as a buffer that can be written down
to a process (byte swapping the Scalar value if needed):

uint32_t
Scalar::GetAsMemoryData (void *dst,
uint32_t dst_len,
lldb::ByteOrder dst_byte_order,
Error &error) const;

The "dst_len" can be smaller that the size of the scalar and the least
significant bytes will be written. "dst_len" can also be larger and the
most significant bytes will be padded with zeroes.

Centralized the code that adds or removes address bits for callable and opcode
addresses into lldb_private::Target:

lldb::addr_t
Target::GetCallableLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const;

lldb::addr_t
Target::GetOpcodeLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const;

All necessary lldb_private::Address functions now use the target versions so
changes should only need to happen in one place if anything needs updating.

Fixed up a lot of places that were calling :

addr_t
Address::GetLoadAddress(Target*);

to call the Address::GetCallableLoadAddress() or Address::GetOpcodeLoadAddress()
as needed. There were many places in the breakpoint code where things could
go wrong for ARM if these weren't used.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131878 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
b9e8f6e7a374d9313f89193e90ae41ef91712e5b 18-May-2011 Greg Clayton <gclayton@apple.com> Added a way to resolve an load address from a target:

bool
Address::SetLoadAddress (lldb::addr_t load_addr, Target *target);

Added an == and != operator to RegisterValue.

Modified the ThreadPlanTracer to use RegisterValue objects to store the
register values when single stepping. Also modified the output to be a bit
less wide.

Fixed the ABIMacOSX_arm to not overwrite stuff on the stack. Also made the
trivial function call be able to set the ARM/Thumbness of the target
correctly, and also sets the return value ARM/Thumbness.

Fixed the encoding on the arm s0-s31 and d16 - d31 registers when the default
register set from a standard GDB server register sets.







git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131517 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
989816b9505219cd67ce044d655c54ac86ecf64b 14-May-2011 Greg Clayton <gclayton@apple.com> Expand the ABI prepare trivial function call to allow 6 simple args.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131334 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
61d4f7adb6936a6d406dd5b20452d0843e538d76 12-May-2011 Greg Clayton <gclayton@apple.com> Cleaned up the ABI::PrepareTrivialCall() function to take three argument
pointers:

virtual bool
PrepareTrivialCall (Thread &thread,
lldb::addr_t sp,
lldb::addr_t functionAddress,
lldb::addr_t returnAddress,
lldb::addr_t *arg1_ptr,
lldb::addr_t *arg2_ptr,
lldb::addr_t *arg3_ptr) const = 0;

Prior to this it was:

virtual bool
PrepareTrivialCall (Thread &thread,
lldb::addr_t sp,
lldb::addr_t functionAddress,
lldb::addr_t returnAddress,
lldb::addr_t arg,
lldb::addr_t *this_arg,
lldb::addr_t *cmd_arg) const = 0;

This was because the function that called this slowly added more features to
be able to call a C++ member function that might have a "this" pointer, and
then later added "self + cmd" support for objective C. Cleaning this code up
and the code that calls it makes it easier to implement the functions for
new targets.

The MacOSX_arm::PrepareTrivialCall() is now filled in and ready for testing.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131221 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
75906e4ec98af3717e415727a8d663a4e246bb4f 11-May-2011 Greg Clayton <gclayton@apple.com> Moved all code from ArchDefaultUnwindPlan and ArchVolatileRegs into their
respective ABI plugins as they were plug-ins that supplied ABI specfic info.

Also hookep up the UnwindAssemblyInstEmulation so that it can generate the
unwind plans for ARM.

Changed the way ABI plug-ins are handed out when you get an instance from
the plug-in manager. They used to return pointers that would be mananged
individually by each client that requested them, but now they are handed out
as shared pointers since there is no state in the ABI objects, they can be
shared.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131193 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
e4b9c1fb338ee1ada72e6a3c198afb342d68c5c1 08-Mar-2011 Greg Clayton <gclayton@apple.com> LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide
an interface to a local or remote debugging platform. By default each host OS
that supports LLDB should be registering a "default" platform that will be
used unless a new platform is selected. Platforms are responsible for things
such as:
- getting process information by name or by processs ID
- finding platform files. This is useful for remote debugging where there is
an SDK with files that might already or need to be cached for debug access.
- getting a list of platform supported architectures in the exact order they
should be selected. This helps the native x86 platform on MacOSX select the
correct x86_64/i386 slice from universal binaries.
- Connect to remote platforms for remote debugging
- Resolving an executable including finding an executable inside platform
specific bundles (macosx uses .app bundles that contain files) and also
selecting the appropriate slice of universal files for a given platform.

So by default there is always a local platform, but remote platforms can be
connected to. I will soon be adding a new "platform" command that will support
the following commands:
(lldb) platform connect --name machine1 macosx connect://host:port
Connected to "machine1" platform.
(lldb) platform disconnect macosx

This allows LLDB to be well setup to do remote debugging and also once
connected process listing and finding for things like:
(lldb) process attach --name x<TAB>

The currently selected platform plug-in can now auto complete any available
processes that start with "x". The responsibilities for the platform plug-in
will soon grow and expand.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@127286 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.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/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.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/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
14243eaa13c8df5baf632c15ab410077c1f4bb55 18-Dec-2010 Sean Callanan <scallanan@apple.com> Fixed the handling of the _cmd parameter in the i386
ABI.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@122118 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
047923c7bc90275f29c2e179d2385df26b8d81a1 14-Dec-2010 Sean Callanan <scallanan@apple.com> Bugfixes for the new "self" pointer handling. Specifically,
the code to pass the _cmd pointer has been improved, and _cmd
is now set to the value of _cmd for the current context, as
opposed to being simply NULL.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@121739 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
3aa7da5cb3327792415de44405e0896c6bdc305b 13-Dec-2010 Sean Callanan <scallanan@apple.com> Added support for generating expressions that have
access to the members of the Objective-C self object.

The approach we take is to generate the method as a
@category on top of the self object, and to pass the
"self" pointer to it. (_cmd is currently NULL.)

Most changes are in ClangExpressionDeclMap, but the
change that adds support to the ABIs to pass _cmd
touches a fair amount of code.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@121722 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
6916e358c9725b75ed91f31236c147f26c9af10e 13-Nov-2010 Greg Clayton <gclayton@apple.com> Modified the lldb_private::Type clang type resolving code to handle three
cases when getting the clang type:
- need only a forward declaration
- need a clang type that can be used for layout (members and args/return types)
- need a full clang type

This allows us to partially parse the clang types and be as lazy as possible.
The first case is when we just need to declare a type and we will complete it
later. The forward declaration happens only for class/union/structs and enums.
The layout type allows us to resolve the full clang type _except_ if we have
any modifiers on a pointer or reference (both R and L value). In this case
when we are adding members or function args or return types, we only need to
know how the type will be laid out and we can defer completing the pointee
type until we later need it. The last type means we need a full definition for
the clang type.

Did some renaming of some enumerations to get rid of the old "DC" prefix (which
stands for DebugCore which is no longer around).

Modified the clang namespace support to be almost ready to be fed to the
expression parser. I made a new ClangNamespaceDecl class that can carry around
the AST and the namespace decl so we can copy it into the expression AST. I
modified the symbol vendor and symbol file plug-ins to use this new class.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@118976 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
462d4147f3bb9141bf62d904f58a623db00669df 29-Sep-2010 Greg Clayton <gclayton@apple.com> Fixed the forward declaration issue that was present in the DWARF parser after
adding methods to C++ and objective C classes. In order to make methods, we
need the function prototype which means we need the arguments. Parsing these
could cause a circular reference that caused an assertion.

Added a new typedef for the clang opaque types which are just void pointers:
lldb::clang_type_t. This appears in lldb-types.h.

This was fixed by enabling struct, union, class, and enum types to only get
a forward declaration when we make the clang opaque qual type for these
types. When they need to actually be resolved, lldb_private::Type will call
a new function in the SymbolFile protocol to resolve a clang type when it is
not fully defined (clang::TagDecl::getDefinition() returns NULL). This allows
us to be a lot more lazy when parsing clang types and keeps down the amount
of data that gets parsed into the ASTContext for each module.

Getting the clang type from a "lldb_private::Type" object now takes a boolean
that indicates if a forward declaration is ok:

clang_type_t lldb_private::Type::GetClangType (bool forward_decl_is_ok);

So function prototypes that define parameters that are "const T&" can now just
parse the forward declaration for type 'T' and we avoid circular references in
the type system.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@115012 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
3c9c5eb466869ede185e879d14a47335fb43194d 21-Sep-2010 Sean Callanan <scallanan@apple.com> Removed the hacky "#define this ___clang_this" handler
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.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@114384 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
3a4ea24572fad1e22525f8efb718d49d41e30398 10-Sep-2010 Jason Molenda <jmolenda@apple.com> The first part of an lldb native stack unwinder.

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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@113581 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
059ce9b34bce8bfa47e40edffc504103dfe07465 07-Sep-2010 Sean Callanan <scallanan@apple.com> Updated the x86_64 and i386 ABIs to chain RBP
(i.e., leave the value the same, so that a new
stack frame will be linked to the previous
stack) rather than zeroing out RBP.

This fixes calls to dlopen(), for example, which
does a backtrace to see which image is calling
it.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@113288 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
960d6a40711f05effe6fcc5b66f0952450f79ea2 03-Aug-2010 Greg Clayton <gclayton@apple.com> Added support for objective C built-in types: id, Class, and SEL. This
involved watching for the objective C built-in types in DWARF and making sure
when we convert the DWARF types into clang types that we use the appropriate
ASTContext types.

Added a way to find and dump types in lldb (something equivalent to gdb's
"ptype" command):

image lookup --type <TYPENAME>

This only works for looking up types by name and won't work with variables.
It also currently dumps out verbose internal information. I will modify it
to dump more appropriate user level info in my next submission.

Hookup up the "FindTypes()" functions in the SymbolFile and SymbolVendor so
we can lookup types by name in one or more images.

Fixed "image lookup --address <ADDRESS>" to be able to correctly show all
symbol context information, but it will only show this extra information when
the new "--verbose" flag is used.

Updated to latest LLVM to get a few needed fixes.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@110089 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.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/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp