summaryrefslogtreecommitdiffstats
path: root/lldb/source/Expression/DWARFExpression.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Use the right dwarf attributes for parsing location list entries (fixup for ↵Pavel Labath2016-10-311-2/+2
| | | | | | | | | | | | | r285441) Note that the parsing code here is still incorrect wrt. the new draft of the dwarf 5 spec (seconds arguments to DW_LLE_startx_length should be uleb128, not u32). Once we have compilers actually emitting dwarf conformant with the new spec, we'll need to revisit this and figure out the proper behavior there. This should unbreak the linux bot. llvm-svn: 285562
* Rename DWARF 5 constants to adapt to change in LLVMAdrian Prantl2016-10-281-3/+3
| | | | llvm-svn: 285441
* Replaced two instances of std::function with auto.Sean Callanan2016-09-141-4/+3
| | | | | | | | Thanks to Zachary Turner for the suggestion. It's distasteful that the actual type of the lambda can't be spelled out, but it should be evident from the definition of the lambda body. llvm-svn: 281536
* Cleaned up some of the "frame diagnose" code to use Operands as currency.Sean Callanan2016-09-131-62/+56
| | | | | | | Also added some utility functions around Operands to make code easier and more compact to write. llvm-svn: 281398
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-3230/+3145
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Added the "frame diagnose" command and use its output to make crash info better.Sean Callanan2016-09-061-0/+148
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When a process stops due to a crash, we get the crashing instruction and the crashing memory location (if there is one). From the user's perspective it is often unclear what the reason for the crash is in a symbolic sense. To address this, I have added new fuctionality to StackFrame to parse the disassembly and reconstruct the sequence of dereferneces and offsets that were applied to a known variable (or fuction retrn value) to obtain the invalid pointer. This makes use of enhancements in the disassembler, as well as new information provided by the DWARF expression infrastructure, and is exposed through a "frame diagnose" command. It is also used to provide symbolic information, when available, in the event of a crash. The algorithm is very rudimentary, and it needs a bunch of work, including - better parsing for assembly, preferably with help from LLVM - support for non-Apple platforms - cleanup of the algorithm core, preferably to make it all work in terms of Operands instead of register/offset pairs - improvement of the GetExpressioPath() logic to make prettier expression paths, and - better handling of vtables. I welcome all suggestios, improvements, and testcases. llvm-svn: 280692
* Added support for thread local variables on all Apple OS variants.Greg Clayton2016-07-011-6/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We had support that assumed that thread local data for a variable could be determined solely from the module in which the variable exists. While this work for linux, it doesn't work for Apple OSs. The DWARF for thread local variables consists of location opcodes that do something like: DW_OP_const8u (x) DW_OP_form_tls_address or DW_OP_const8u (x) DW_OP_GNU_push_tls_address The "x" is allowed to be anything that is needed to determine the location of the variable. For Linux "x" is the offset within the TLS data for a given executable (ModuleSP in LLDB). For Apple OS variants, it is the file address of the data structure that contains a pthread key that can be used with pthread_getspecific() and the offset needed. This fix passes the "x" along to the thread: virtual lldb::addr_t lldb_private::Thread::GetThreadLocalData(const lldb::ModuleSP module, lldb::addr_t tls_file_addr); Then this is passed along to the DynamicLoader::GetThreadLocalData(): virtual lldb::addr_t lldb_private::DynamicLoader::GetThreadLocalData(const lldb::ModuleSP module, const lldb::ThreadSP thread, lldb::addr_t tls_file_addr); This allows each DynamicLoader plug-in do the right thing for the current OS. The DynamicLoaderMacOSXDYLD was modified to be able to grab the pthread key from the data structure that is in memory and call "void *pthread_getspecific(pthread_key_t key)" to get the value of the thread local storage and it caches it per thread since it never changes. I had to update the test case to access the thread local data before trying to print it as on Apple OS variants, thread locals are not available unless they have been accessed at least one by the current thread. I also added a new lldb::ValueType named "eValueTypeVariableThreadLocal" so that we can ask SBValue objects for their ValueType and be able to tell when we have a thread local variable. <rdar://problem/23308080> llvm-svn: 274366
* DWARFExpression: Don't resolve load address in DW_OP_plusTamas Berghammer2016-03-011-3/+3
| | | | | | | | | If we have a TargetLoadAddress on the top of the DWARF stack then a DW_OP_plus or a DW_OP_plus_ucons sholudn't dereference (resolve) it and then add the value to the dereferenced value but it should offset the load address by the specified constant. llvm-svn: 262339
* Revert part of rL262014 as it caused issues on gcc-i386Tamas Berghammer2016-02-261-4/+0
| | | | llvm-svn: 262023
* Add support for DW_OP_push_object_address in dwarf expressionsTamas Berghammer2016-02-261-4/+27
| | | | | | | | | Additionally fix the type of some dwarf expression where we had a confusion between scalar and load address types after a dereference. Differential revision: http://reviews.llvm.org/D17604 llvm-svn: 262014
* Moved more Clang-specific parts of the expression parser into the Clang plugin.Sean Callanan2015-09-251-1/+1
| | | | | | | | | There are still a bunch of dependencies on the plug-in, but this helps to identify them. There are also a few more bits we need to move (and abstract, for example the ClangPersistentVariables). llvm-svn: 248612
* Fix MSVC warings in DWARFExpression.cppTamas Berghammer2015-09-211-1/+2
| | | | llvm-svn: 248148
* Add support for the DWARFLocationList used by split-dwarfTamas Berghammer2015-09-161-238/+317
| | | | | | | | | Split-dwarf uses a different header format to specify the address range for the elements of the location lists. Differential revision: http://reviews.llvm.org/D12880 llvm-svn: 247789
* Add support for DW_OP_GNU_const_index to dwarf expressionTamas Berghammer2015-09-151-3/+45
| | | | | | | | DW_OP_GNU_const_index is a new opcode used when split dwarf is enabled Differential revision: http://reviews.llvm.org/D12849 llvm-svn: 247672
* Remove an invalid check in DW_OP_piece processing.Hafiz Abid Qadeer2015-09-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: When lldb is processing a location containing DW_OP_piece, the result is being stored in the 'pieces' variable. The location is popped from the 'stack' variable. So this check to see that 'stack' is not empty was invalid and caused the pieces after the first to not get processed. I am working on an architecture which has 16-bit and 8-bit registers. So this problem was quite easy to see. But I was able to re-produce this issue on x86 too with long long variable and compiling woth -m32. It resulted in following location list. 00000014 08048496 080484b5 (DW_OP_reg6 (esi); DW_OP_piece: 4; DW_OP_reg7 (edi); DW_OP_piece: 4) and lldb was only showing the contents of first register when I evaluated the variable as it does not process the 2nd piece due to this check. Reviewers: clayborg, aprantl Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12674 llvm-svn: 247124
* Jim told me about a cleaner way to include headers from plug-ins.Sean Callanan2015-09-031-1/+1
| | | | | | | | This is still something I need to fix, but at least it's not so ugly, and it's consistent with the other code that does that so we will catch it when we purge all such code. llvm-svn: 246738
* In preparation for factoring persistent variables into a generic part and aSean Callanan2015-09-031-1/+1
| | | | | | | | | | | | Clang-specific part, create the ExpressionVariable source/header file and move ClangExpressionVariable into the Clang expression parser plugin. It is expected that there are some ugly #include paths... these will be resolved by either (1) making that code use generic expression variables (once they're separated appropriately) or (2) moving that code into a plug-in, often the expression parser plug-in. llvm-svn: 246737
* Handle DW_OP_GNU_addr_index in DWARF expressionsTamas Berghammer2015-08-251-6/+91
| | | | | | Differential revision: http://reviews.llvm.org/D12290 llvm-svn: 245932
* Move lldb-log.cpp to core/Logging.cppZachary Turner2015-03-181-2/+0
| | | | | | | | | So that we don't have to update every single #include in the entire codebase to #include this new header (which used to get included by lldb-private-log.h, we automatically #include "Logging.h" from within "Log.h". llvm-svn: 232653
* Add support for the DWARFv3 (circa 2005) DW_OP_form_tls_addressJason Molenda2015-03-051-4/+13
| | | | | | | | | | | | | operator in addition to the vendor-extension DW_OP_GNU_push_tls_address. clang on PS4 and Darwin will be emitting the standard opcode as of r231286 via http://reviews.llvm.org/D8018 Behavior of this standard opcode is the same as DW_OP_GNU_push_tls_address. <rdar://problem/20043195> llvm-svn: 231342
* Don't crash when evaluating a DWARF expression has a DW_OP_bra with nothing ↵Greg Clayton2015-02-101-0/+7
| | | | | | | | on the value stack. <rdar://problem/18919125> llvm-svn: 228729
* Ryan Brown's patch to handle DW_OP_call_frame_cfa addressesJason Molenda2014-10-161-1/+1
| | | | | | | as load addreses instead of host addresses. http://reviews.llvm.org/D5735 llvm-svn: 219896
* Ah, accidentally committed a patch I didn't mean to. Jason Molenda2014-10-161-1/+1
| | | | llvm-svn: 219888
* It's possible for long_options[long_options_index].definition to be nullJason Molenda2014-10-161-1/+1
| | | | | | | | from the previous for() loop - check that it is non-null before trying to deref it. clang static analyzer fixit. llvm-svn: 219887
* Fix -Werror,-Wcovered-switch-default warning in DWARFExpressionEric Christopher2014-09-091-5/+0
| | | | | | | as part of an attempt to get lldb building inside llvm with -Werror enabled. llvm-svn: 217418
* Fix typo in error message.Eric Christopher2014-08-141-1/+1
| | | | llvm-svn: 215681
* Patch to enable LLDB to extract value bytes from DWARF block forms and ↵Enrico Granata2014-08-111-3/+30
| | | | | | udata/sdata forms. By Greg Clayton llvm-svn: 215379
* Rewrote the initial DW_OP_piece support to be able to support opcodes like:Greg Clayton2014-07-311-108/+145
| | | | | | | | | | | | | | | | | | DW_OP_fbreg(N) DW_OP_piece(4) DW_OP_fbreg(M) DW_OP_piece(8) DW_OP_fbreg(N) DW_OP_piece(4) DW_OP_piece(8) The first grabs 4 bytes from FP+N followed by 8 bytes from FP+M, the second grabs 4 bytes from FP+N followed by zero filling 8 bytes which are unavailable. Of course regiters are stuff supported: DW_OP_reg3 DW_OP_piece(4) DW_OP_reg8 DW_OP_piece(8) The fix does the following: 1 - don't push the full piece value onto the stack, keep it on the side 2 - fill zeros for DW_OP_piece(N) opcodes that have nothing on the stack (instead of previously consuming the full piece that was pushed onto the stack) 3 - simplify the logic <rdar://problem/16930524> llvm-svn: 214415
* lldb is a scope, not a labelEd Maste2014-07-301-1/+1
| | | | llvm-svn: 214327
* Use Process::ReadMemoryFromPointer() instead of manually reading the pointer.Greg Clayton2014-07-301-6/+3
| | | | llvm-svn: 214323
* lldb needs to support DW_op_piece masks for values in subregister and also ↵Greg Clayton2014-07-121-2/+76
| | | | | | | | | | to be able to piece together a value that is spread across multiple registers. Patch from Adrian Prantl. <rdar://problem/16040521> llvm-svn: 212867
* Replace uint32_t by lldb::RegisterKing in register context API.Jean-Daniel Dupas2014-07-021-2/+2
| | | | llvm-svn: 212172
* "size_t" isn't always 64 bit, it is 32 bit on 32 bit systems. All printf ↵Greg Clayton2014-03-031-2/+2
| | | | | | | | style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed. If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64. llvm-svn: 202738
* Fix Windows build using portable types for formatting the log outputsDeepak Panickal2014-03-031-2/+2
| | | | llvm-svn: 202723
* Add support for DW_OP_piece and DW_OP_bit_piece.Greg Clayton2014-02-121-3/+84
| | | | llvm-svn: 201268
* Avoid LLDB crash upon DW_OP_deref* with empty stackEd Maste2014-01-131-0/+12
| | | | | | | | As done in other DW_OP_* cases, return an error if the stack is empty rather than eventually crashing elsewhere. Encountered on big-endian MIPS, where LLVM bugs currently result in invalid .debug_loc data. llvm-svn: 199110
* Roll back the changes I made in r193907 which created a new FrameJason Molenda2013-11-041-3/+3
| | | | | | | | | | pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
* Add a new base class, Frame. It is a pure virtual function whichJason Molenda2013-11-021-3/+3
| | | | | | | | | | | | | | | | | | | | | defines a protocol that all subclasses will implement. StackFrame is currently the only subclass and the methods that Frame vends are nearly identical to StackFrame's old methods. Update all callers to use Frame*/Frame& instead of pointers to StackFrames. This is almost entirely a mechanical change that touches a lot of the code base so I'm committing it alone. No new functionality is added with this patch, no new subclasses of Frame exist yet. I'll probably need to tweak some of the separation, possibly moving some of StackFrame's methods up in to Frame, but this is a good starting point. <rdar://problem/15314068> llvm-svn: 193907
* Fix the format warnings.Sylvestre Ledru2013-10-311-2/+2
| | | | | | | | | | In almost all cases, the misuse is about "%lu" being used instead of the correct "%zu" (even though these are compatible on 64-bit platforms in practice). There are even a couple of cases where "%ld" (ie., signed int) is used instead of "%zu", and one where "%lu" is used instead of "%" PRIu64. Fixes bug #17551. Patch by "/dev/humancontroller" llvm-svn: 193832
* Added support for reading thread-local storage variables, as defined using ↵Richard Mitton2013-10-171-6/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | the __thread modifier. To make this work this patch extends LLDB to: - Explicitly track the link_map address for each module. This is effectively the module handle, not sure why it wasn't already being stored off anywhere. As an extension later, it would be nice if someone were to add support for printing this as part of the modules list. - Allow reading the per-thread data pointer via ptrace. I have added support for Linux here. I'll be happy to add support for FreeBSD once this is reviewed. OS X does not appear to have __thread variables, so maybe we don't need it there. Windows support should eventually be workable along the same lines. - Make DWARF expressions track which module they originated from. - Add support for the DW_OP_GNU_push_tls_address DWARF opcode, as generated by gcc and recent versions of clang. Earlier versions of clang (such as 3.2, which is default on Ubuntu right now) do not generate TLS debug info correctly so can not be supported here. - Understand the format of the pthread DTV block. This is where it gets tricky. We have three basic options here: 1) Call "dlinfo" or "__tls_get_addr" on the inferior and ask it directly. However this won't work on core dumps, and generally speaking it's not a good idea for the debugger to call functions itself, as it has the potential to not work depending on the state of the target. 2) Use libthread_db. This is what GDB does. However this option requires having a version of libthread_db on the host cross-compiled for each potential target. This places a large burden on the user, and would make it very hard to cross-debug from Windows to Linux, for example. Trying to build a library intended exclusively for one OS on a different one is not pleasant. GDB sidesteps the problem and asks the user to figure it out. 3) Parse the DTV structure ourselves. On initial inspection this seems to be a bad option, as the DTV structure (the format used by the runtime to manage TLS data) is not in fact a kernel data structure, it is implemented entirely in useerland in libc. Therefore the layout of it's fields are version and OS dependent, and are not standardized. However, it turns out not to be such a problem. All OSes use basically the same algorithm (a per-module lookup table) as detailed in Ulrich Drepper's TLS ELF ABI document, so we can easily write code to decode it ourselves. The only question therefore is the exact field layouts required. Happily, the implementors of libpthread expose the structure of the DTV via metadata exported as symbols from the .so itself, designed exactly for this kind of thing. So this patch simply reads that metadata in, and re-implements libthread_db's algorithm itself. We thereby get cross-platform TLS lookup without either requiring third-party libraries, while still being independent of the version of libpthread being used. Test case included. llvm-svn: 192922
* Remove some unused #includes.Jim Ingham2013-09-051-4/+0
| | | | llvm-svn: 190025
* Cleanup/rearrange includes:Virgile Bello2013-08-281-0/+4
| | | | | | | - factorize unistd.h and stdbool.h in lldb-types.h. - Add <functional> and <string> where required. llvm-svn: 189477
* Reverts r187449 (report_fatal_error) in favor of a log message sinceAshok Thirumurthi2013-07-311-3/+3
| | | | | | | | the extra check introduces 22 new test failures with the LLDB clang buildbot. Note that the unhandled DWARF_OP codes in DWARFExpression::Evaluate don't cause test failures if the check is ignored. llvm-svn: 187480
* Add a default case to the LLVM expression opcode switch statementDaniel Malea2013-07-301-0/+4
| | | | | | - better than failing silently next time the DWARF standard introduces new opcodes! llvm-svn: 187449
* Adds a DW_OP_call_frame_cfa handler when evaluating DWARF 3/4 expressionsAshok Thirumurthi2013-07-291-0/+32
| | | | | | | | | | | | | | in LLDB that load the canonical frame address rather than a location list. - Handles the simple case where a CFA can be pulled from the current stack frame. - Fixes more than one hundred failing tests with gcc 4.8! TODO: Use UnwindPlan::GetRowForFunctionOffset if the DWARFExpression needs to be evaluated in a context analogous to a virtual unwind (perhaps using RegisterContextLLDB). - Also adds some comments to DWARFCallFrameInfo whenever I got confused. llvm-svn: 187361
* Huge change to clean up types.Greg Clayton2013-07-111-593/+30
| | | | | | | | 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/13893094>Greg Clayton2013-05-171-1/+8
| | | | | | Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
* After discussing with Chris Lattner, we require C++11, so lets get rid of ↵Greg Clayton2013-04-181-1/+1
| | | | | | the macros and just use C++11. llvm-svn: 179805
* Since we use C++11, we should switch over to using std::unique_ptr when ↵Greg Clayton2013-04-181-2/+2
| | | | | | | | C++11 is being used. To do this, we follow what we have done for shared pointers and we define a STD_UNIQUE_PTR macro that can be used and it will "do the right thing". Due to some API differences in std::unique_ptr and due to the fact that we need to be able to compile without C++11, we can't use move semantics so some code needed to change so that it can compile with either C++. Anyone wanting to use a unique_ptr or auto_ptr should now use the "STD_UNIQUE_PTR(TYPE)" macro. llvm-svn: 179779
* <rdar://problem/13521159>Greg Clayton2013-03-271-1/+1
| | | | | | | | LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
OpenPOWER on IntegriCloud