summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/ABI/MacOSX-i386
Commit message (Collapse)AuthorAgeFilesLines
...
* Fixing build errors from r188952Andrew Kaylor2013-08-211-2/+2
| | | | llvm-svn: 188955
* Adding separate cfa alignment check for Darwin and non-Darwin targets in ↵Andrew Kaylor2013-08-212-8/+34
| | | | | | 32-bit ABI. llvm-svn: 188952
* Huge change to clean up types.Greg Clayton2013-07-111-67/+38
| | | | | | | | 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. llvm-svn: 186130
* <rdar://problem/13854277>Greg Clayton2013-05-102-18/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | <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. llvm-svn: 181631
* Adding CMake build system to LLDB. Some known issues remain:Daniel Malea2013-02-211-0/+5
| | | | | | | | | | | | | | - generate-vers.pl has to be called by cmake to generate the version number - parallel builds not yet supported; dependency on clang must be explicitly specified Tested on Linux. - Building on Mac will require code-signing logic to be implemented. - Building on Windows will require OS-detection logic and some selective directory inclusion Thanks to Carlo Kok (who originally prepared these CMakefiles for Windows) and Ben Langmuir who ported them to Linux! llvm-svn: 175795
* <rdar://problem/13069948>Greg Clayton2013-01-251-1/+1
| | | | | | | | | | | | 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. llvm-svn: 173463
* More Linux warnings fixes (remove default labels as needed):Daniel Malea2012-12-071-1/+0
| | | | | | | | - as per http://llvm.org/docs/CodingStandards.html#don-t-use-default-labels-in-fully-covered-switches-over-enumerations Patch by Matt Kopec! llvm-svn: 169633
* Fix ABIMacOSX_i386::RegisterIsVolatile to return the negated value of Jason Molenda2012-12-061-2/+2
| | | | | | | | RegisterIsCalleeSaved. Add ebp back to the list of registers that are callee saved. <rdar://problem/12817918> llvm-svn: 169466
* Backed out part of the ABI changes that were checked in because it breaks ↵Greg Clayton2012-12-051-1/+1
| | | | | | | | | | 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 llvm-svn: 169409
* Fix comment in ABIMacOSX_i386::RegisterIsCalleeSaved to say thatJason Molenda2012-12-041-2/+10
| | | | | | | | these are the *non-volatile* registers on Darwin/i386, not the volatile registers. Recognize the sp, pc, fp generic reg names as well. llvm-svn: 169316
* Add a new capability to RegisterContextLLDB: To recognize when theJason Molenda2012-10-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 166757
* Add a new ABI plugin method which specifies whether the architectureJason Molenda2012-10-161-1/+7
| | | | | | | | | | | | | | | must push something on the stack for a function call or not. In x86, the stack pointer is decremented when the caller's pc is saved on the stack. In arm, the stack pointer and frame pointer don't necessarily have to change for a function call, although most functions need to use some stack space during their execution. Use this information in the RegisterContextLLDB to detect invalid unwind scenarios more accurately. <rdar://problem/12348574> llvm-svn: 166005
* Made the i386 ABI mark EBP as non-volatile,Sean Callanan2012-10-041-1/+1
| | | | | | | because the unwinders typically can find its value. llvm-svn: 165266
* Implement returning integer values in "thread return" for arm, x86_64 and ↵Jim Ingham2012-09-271-7/+80
| | | | | | | | | | i386. Also returns floats & doubles on x86_64. <rdar://problem/8356523> llvm-svn: 164741
* Fix string comparisons in ABIMacOSX_i386::RegisterIsCalleeSaved soJason Molenda2012-09-241-4/+4
| | | | | | | | that volatile registers are correctly reported for this ABI. We were incorrectly passing up volatile registers from callee frames. llvm-svn: 164564
* Start at getting "thread return" working. Doesn't work yet.Jim Ingham2012-09-122-0/+10
| | | | llvm-svn: 163670
* Switch nearly all of the use of the UnwindPlan::Row's to go throughJason Molenda2012-07-141-11/+11
| | | | | | | | | | | | | | 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. llvm-svn: 160214
* Simplify the CreateDefaultUnwindPlan methods for the x86 and arm unwindersJason Molenda2012-07-091-37/+5
| | | | | | | | | 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. llvm-svn: 159924
* On i386 we see occasional crashes when the registerSean Callanan2012-07-071-0/+2
| | | | | | | | | context is not returning valid registers yet. Don't crash in these situations. <rdar://problem/11650335> llvm-svn: 159885
* rdar://problem/10652076Johnny Chen2012-02-291-51/+51
| | | | | | | | | | | | | | | | | | | 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) llvm-svn: 151686
* Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptrGreg Clayton2012-02-211-25/+28
| | | | | | | | | | | | | | | | | 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. llvm-svn: 151009
* Improve the x86_64 return value decoder to handle most structure returns.Jim Ingham2011-12-222-78/+86
| | | | | | | | 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. llvm-svn: 147157
* Have the FuncUnwinder object request & provide an architecture-definedJason Molenda2011-09-151-1/+1
| | | | | | | | | | | | | | | | | | | | | 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(); } llvm-svn: 139760
* Added a new plug-in type: lldb_private::OperatingSystem. The operating system Greg Clayton2011-08-222-113/+195
| | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 138228
* ABI plug-ins must implement the following pure virtual functions:Greg Clayton2011-05-241-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | virtual bool ABI::StackUsesFrames () = 0; Should return true if your ABI uses frames when doing stack backtraces. This means a frame pointer is used that points to the previous stack frame in some way or another. virtual bool ABI::CallFrameAddressIsValid (lldb::addr_t cfa) = 0; Should take a look at a call frame address (CFA) which is just the stack pointer value upon entry to a function. ABIs usually impose alignment restrictions (4, 8 or 16 byte aligned), and zero is usually not allowed. This function should return true if "cfa" is valid call frame address for the ABI, and false otherwise. This is used by the generic stack frame unwinding code to help determine when a stack ends. virtual bool ABI::CodeAddressIsValid (lldb::addr_t pc) = 0; Validates a possible PC value and returns true if an opcode can be at "pc". Some ABIs or architectures have fixed width instructions and must be aligned to a 2 or 4 byte boundary. "pc" can be an opcode or a callable address which means the load address might be decorated with extra bits (such as bit zero to indicate a thumb function call for ARM targets), so take this into account when returning true or false. The address should also be validated to ensure it is a valid address for the address size of the inferior process. 32 bit targets should make sure the address is less than UINT32_MAX. Modified UnwindLLDB to use the new ABI functions to help it properly terminate stacks. Modified the mach-o function that extracts dependent files to not resolve the path as the paths inside a binary might not match those on the current host system. llvm-svn: 132021
* Added new lldb_private::Process memory read/write functions to stop a bunchGreg Clayton2011-05-221-73/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 131878
* Fix trailing commas at the end of enumerator lists.Charles Davis2011-05-191-1/+1
| | | | | | Seriously, I have no idea how you guys managed to build LLDB before. llvm-svn: 131684
* Added a way to resolve an load address from a target:Greg Clayton2011-05-181-2/+2
| | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 131517
* Expand the ABI prepare trivial function call to allow 6 simple args.Greg Clayton2011-05-142-23/+81
| | | | llvm-svn: 131334
* Cleaned up the ABI::PrepareTrivialCall() function to take three argumentGreg Clayton2011-05-122-76/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 131221
* Moved all code from ArchDefaultUnwindPlan and ArchVolatileRegs into theirGreg Clayton2011-05-112-65/+333
| | | | | | | | | | | | | | | 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. llvm-svn: 131193
* LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provideGreg Clayton2011-03-082-26/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 127286
* Made lldb_private::ArchSpec contain much more than just an architecture. ItGreg Clayton2011-02-152-9/+6
| | | | | | | | | | now, in addition to cpu type/subtype and architecture flavor, contains: - byte order (big endian, little endian) - address size in bytes - llvm::Triple for true target triple support and for more powerful plug-in selection. llvm-svn: 125602
* Fixed issues with RegisterContext classes and the subclasses. There wasGreg Clayton2011-01-061-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | an issue with the way the UnwindLLDB was handing out RegisterContexts: it was making shared pointers to register contexts and then handing out just the pointers (which would get put into shared pointers in the thread and stack frame classes) and cause double free issues. MallocScribble helped to find these issues after I did some other cleanup. To help avoid any RegisterContext issue in the future, all code that deals with them now returns shared pointers to the register contexts so we don't end up with multiple deletions. Also now that the RegisterContext class doesn't require a stack frame, we patched a memory leak where a StackFrame object was being created and leaked. Made the RegisterContext class not have a pointer to a StackFrame object as one register context class can be used for N inlined stack frames so there is not a 1 - 1 mapping. Updates the ExecutionContextScope part of the RegisterContext class to never return a stack frame to indicate this when it is asked to recreate the execution context. Now register contexts point to the concrete frame using a concrete frame index. Concrete frames are all of the frames that are actually formed on the stack of a thread. These concrete frames can be turned into one or more user visible frames due to inlining. Each inlined stack frame has the exact same register context (shared via shared pointers) as any parent inlined stack frames all the way up to the concrete frame itself. So now the stack frames and the register contexts should behave much better. llvm-svn: 122976
* Fixed the handling of the _cmd parameter in the i386Sean Callanan2010-12-181-2/+2
| | | | | | ABI. llvm-svn: 122118
* Bugfixes for the new "self" pointer handling. Specifically,Sean Callanan2010-12-141-1/+1
| | | | | | | | 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. llvm-svn: 121739
* Added support for generating expressions that haveSean Callanan2010-12-132-3/+20
| | | | | | | | | | | | | | 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. llvm-svn: 121722
* Modified the lldb_private::Type clang type resolving code to handle threeGreg Clayton2010-11-131-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 118976
* Fixed the forward declaration issue that was present in the DWARF parser afterGreg Clayton2010-09-291-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 115012
* Removed the hacky "#define this ___clang_this" handlerSean Callanan2010-09-212-7/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | for C++ classes. Replaced it with a less hacky approach: - If an expression is defined in the context of a method of class A, then that expression is wrapped as ___clang_class::___clang_expr(void*) { ... } instead of ___clang_expr(void*) { ... }. - ___clang_class is resolved as the type of the target of the "this" pointer in the method the expression is defined in. - When reporting the type of ___clang_class, a method with the signature ___clang_expr(void*) is added to that class, so that Clang doesn't complain about a method being defined without a corresponding declaration. - Whenever the expression gets called, "this" gets looked up, type-checked, and then passed in as the first argument. This required the following changes: - The ABIs were changed to support passing of the "this" pointer as part of trivial calls. - ThreadPlanCallFunction and ClangFunction were changed to support passing of an optional "this" pointer. - ClangUserExpression was extended to perform the wrapping described above. - ClangASTSource was changed to revert the changes required by the hack. - ClangExpressionParser, IRForTarget, and ClangExpressionDeclMap were changed to handle different manglings of ___clang_expr flexibly. This meant no longer searching for a function called ___clang_expr, but rather looking for a function whose name *contains* ___clang_expr. - ClangExpressionParser and ClangExpressionDeclMap now remember whether "this" is required, and know how to look it up as necessary. A few inheritance bugs remain, and I'm trying to resolve these. But it is now possible to use "this" as well as refer implicitly to member variables, when in the proper context. llvm-svn: 114384
* The first part of an lldb native stack unwinder.Jason Molenda2010-09-101-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Unwind and RegisterContext subclasses still need to be finished; none of this code is used by lldb at this point (unless you call into it by hand). The ObjectFile class now has an UnwindTable object. The UnwindTable object has a series of FuncUnwinders objects (Function Unwinders) -- one for each function in that ObjectFile we've backtraced through during this debug session. The FuncUnwinders object has a few different UnwindPlans. UnwindPlans are a generic way of describing how to find the canonical address of a given function's stack frame (the CFA idea from DWARF/eh_frame) and how to restore the caller frame's register values, if they have been saved by this function. UnwindPlans are created from different sources. One source is the eh_frame exception handling information generated by the compiler for unwinding an exception throw. Another source is an assembly language inspection class (UnwindAssemblyProfiler, uses the Plugin architecture) which looks at the instructions in the funciton prologue and describes the stack movements/register saves that are done. Two additional types of UnwindPlans that are worth noting are the "fast" stack UnwindPlan which is useful for making a first pass over a thread's stack, determining how many stack frames there are and retrieving the pc and CFA values for each frame (enough to create StackFrameIDs). Only a minimal set of registers is recovered during a fast stack walk. The final UnwindPlan is an architectural default unwind plan. These are provided by the ArchDefaultUnwindPlan class (which uses the plugin architecture). When no symbol/function address range can be found for a given pc value -- when we have no eh_frame information and when we don't have a start address so we can't examine the assembly language instrucitons -- we have to make a best guess about how to unwind. That's when we use the architectural default UnwindPlan. On x86_64, this would be to assume that rbp is used as a stack pointer and we can use that to find the caller's frame pointer and pc value. It's a last-ditch best guess about how to unwind out of a frame. There are heuristics about when to use one UnwindPlan versues the other -- this will all happen in the still-begin-written UnwindLLDB subclass of Unwind which runs the UnwindPlans. llvm-svn: 113581
* Updated the x86_64 and i386 ABIs to chain RBPSean Callanan2010-09-071-2/+7
| | | | | | | | | | | | (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. llvm-svn: 113288
* Added support for objective C built-in types: id, Class, and SEL. This Greg Clayton2010-08-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 110089
* Merged Eli Friedman's linux build changes where he added Makefile files thatGreg Clayton2010-07-091-0/+14
| | | | | | | enabled LLVM make style building and made this compile LLDB on Mac OS X. We can now iterate on this to make the build work on both linux and macosx. llvm-svn: 108009
* Initial checkin of lldb code from internal Apple repo.Chris Lattner2010-06-082-0/+671
llvm-svn: 105619
OpenPOWER on IntegriCloud