summaryrefslogtreecommitdiff
path: root/source/Plugins/SymbolFile/DWARF/DWARFDebugLine.h
AgeCommit message (Collapse)Author
2019-08-13[DWARF} Use LLVM's debug line parser in LLDB.Jonas Devlieghere
The line number table header was substantially revised in DWARF 5 and is not fully supported by LLDB's current debug line implementation. This patch replaces the LLDB debug line parser with its counterpart in LLVM. This was possible because of the limited contact surface between the code to parse the DWARF debug line section and the rest of LLDB. We pay a small cost in terms of performance and memory usage. This is something we plan to address in the near future. Differential revision: https://reviews.llvm.org/D62570 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@368742 91177308-0d34-0410-b5e6-96231b3b80d8
2019-08-06[SymbolFile] Remove commented out methodAlex Langford
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@368075 91177308-0d34-0410-b5e6-96231b3b80d8
2019-06-07[lldb] Fix msan use-of-uninitialized-value in DWARFDebugLine::FileNameEntry.Jorge Gorbe Moya
lldb/lit/SymbolFile/DWARF/debug-types-expressions.test fails with msan. This change fixes the issue by ensuring FileNameEntry::checksum is always default-initialized. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@362843 91177308-0d34-0410-b5e6-96231b3b80d8
2019-04-10[NFC] Remove ASCII lines from commentsJonas Devlieghere
A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment. Its use is not really consistent across the code base, sometimes the lines are longer, sometimes they are shorter and sometimes they are omitted. Furthermore, it looks kind of weird with the 80 column limit, where the comment actually extends past the line, but not by much. Furthermore, when /// is used for Doxygen comments, it looks particularly odd. And when // is used, it incorrectly gives the impression that it's actually a Doxygen comment. I assume these lines were added to improve distinguishing between comments and code. However, given that todays editors and IDEs do a great job at highlighting comments, I think it's worth to drop this for the sake of consistency. The alternative is fixing all the inconsistencies, which would create a lot more churn. Differential revision: https://reviews.llvm.org/D60508 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@358135 91177308-0d34-0410-b5e6-96231b3b80d8
2019-03-19Delete dead code.Zachary Turner
Most of these are Dump functions that are never called, but there is one instance of entire unused classes (DWARFDebugMacinfo and DWARFDebugMacinfoEntry) which are also unreferenced in the codebase). Differential Revision: https://reviews.llvm.org/D59276 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@356490 91177308-0d34-0410-b5e6-96231b3b80d8
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@351636 91177308-0d34-0410-b5e6-96231b3b80d8
2019-01-16DWARF: Add some support for non-native directory separatorsPavel Labath
Summary: If we opened a file which was produced on system with different path syntax, we would parse the paths from the debug info incorrectly. The reason for that is that we would parse the paths as they were native. For example this meant that on linux we would treat the entire windows path as a single file name with no directory component, and then we would concatenate that with the single directory component from the DW_AT_comp_dir attribute. When parsing posix paths on windows, we would at least get the directory separators right, but we still would treat the posix paths as relative, and concatenate them where we shouldn't. This patch attempts to remedy this by guessing the path syntax used in each compile unit. (Unfortunately, there is no info in DWARF which would give the definitive path style used by the produces, so guessing is all we can do.) Currently, this guessing is based on the DW_AT_comp_dir attribute of the compile unit, but this can be refined later if needed (for example, the DW_AT_name of the compile unit may also contain some useful info). This style is then used when parsing the line table of that compile unit. This patch is sufficient to make the line tables come out right, and enable breakpoint setting by file name work correctly. Setting a breakpoint by full path still has some kinks (specifically, using a windows-style full path will not work on linux because the path will be parsed as a linux path), but this will require larger changes in how breakpoint setting works. Reviewers: clayborg, zturner, JDevlieghere Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D56543 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@351328 91177308-0d34-0410-b5e6-96231b3b80d8
2018-09-13[LLDB] - Improved DWARF5 support.George Rimar
This patch improves the support of DWARF5. Particularly the reporting of source code locations. Differential revision: https://reviews.llvm.org/D51935 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@342153 91177308-0d34-0410-b5e6-96231b3b80d8
2018-04-27Always normalize FileSpec paths.Greg Clayton
Always normalizing lldb_private::FileSpec paths will help us get a consistent results from comparisons when setting breakpoints and when looking for source files. This also removes a lot of complexity from the comparison routines. Modified the DWARF line table parser to use the normalized compile unit directory if needed. Differential Revision: https://reviews.llvm.org/D45977 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@331049 91177308-0d34-0410-b5e6-96231b3b80d8
2016-09-06*** This commit represents a complete reformatting of the LLDB source codeKate Stone
*** 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. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@280751 91177308-0d34-0410-b5e6-96231b3b80d8
2015-10-26Re-use prologue parsing code that was already written instead of having two ↵Greg Clayton
copies of code that parse line table prologues. Also since we always read in the DWARF data or mmap it, we don't need to make a copy of the strings for the directories and file names, we can just store "cosnt char *" values. Every place that uses the prologues use them temporarily and then throw them away so no one is expecting the directory and filename strings to live longer than the parse functions. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@251310 91177308-0d34-0410-b5e6-96231b3b80d8
2015-08-27More cleanup to make sure no one plays with DWARFDebugInfoEntry. Clients ↵Greg Clayton
outside of DWARFDebugInfoEntry of DWARFCompileUnit should use DWARFDIE only. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@246172 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-29dwarf: add dwarf v4 maximum_operations_per_instruction to DWARFDebugLine.Todd Fiala
See http://reviews.llvm.org/D5533 for details. Change by Tong Shen. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@218641 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-31Migrate DWARFDebugLine to DWARFDataExtractor 64-bit DWARF supportEd Maste
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@193794 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-31Remove unused DWARFDebugLine length functionsEd Maste
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@193792 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-24Introduce DWARFDataExtractor for 64-Bit DWARF parsingEd Maste
Review: http://llvm-reviews.chandlerc.com/D2007 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@193368 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-23Initial DWARF64 support for .debug_lineEd Maste
Some versions of the GNU MIPS toolchain generate 64-Bit DWARF (even though it isn't really necessary). This change adds support for the 64-Bit DWARF format, but is not actually tested with >4GB of debug data. Similar changes are in progress for llvm's version of DWARFDebugLine, in review D1988. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@193242 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-18After discussing with Chris Lattner, we require C++11, so lets get rid of ↵Greg Clayton
the macros and just use C++11. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179805 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-25<rdar://problem/13069948>Greg Clayton
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
2012-05-23Small fixes: actually return a boolean and remove semi-colons.Filipe Cabecinhas
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@157328 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-15<rdar://problem/8196933>Greg Clayton
Use the metadata in the dSYM bundle Info.plist to remap source paths when they keys are available. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@152836 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-14<rdar://problem/10434005>Greg Clayton
Prepare LLDB to be built with C++11 by hiding all accesses to std::tr1 behind macros that allows us to easily compile for either C++. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@152698 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-29Switching back to using std::tr1::shared_ptr. We originally switched awayGreg Clayton
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
2011-09-12Fixed the header guards.Greg Clayton
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@139490 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-08Spelling changes applied from lldb_spelling.diffs from Bruce Mitchener.Greg Clayton
Thanks Bruce! git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@123083 91177308-0d34-0410-b5e6-96231b3b80d8
2010-06-08Initial checkin of lldb code from internal Apple repo.Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@105619 91177308-0d34-0410-b5e6-96231b3b80d8