summaryrefslogtreecommitdiffstats
path: root/lldb/source/Symbol/LineTable.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [lldb] Use llvm range functions in LineTable.cppPavel Labath2019-12-031-6/+2
| | | | to avoid needing to declare iterators everywhere.
* Fix line table resolution near the end of a sectionPavel Labath2019-08-061-27/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: lld r367537 changed the way the linker organizes sections and segments. This exposed an lldb bug and caused some tests to fail. In all of the failing tests the root cause was the same -- when we were trying to resolve the last address in the line_table section, we failed because it pointed past the end of the section. This patch changes the line table address resolution code to back up the address by one for end-of-sequence entries. This ensures the address still points inside a section/module even if the line table sequence ends at the very end of a section. It also reverts the linker flags which were added to the failing tests to restore previous behavior. Reviewers: clayborg, jingham Subscribers: mgorny, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D65647 llvm-svn: 367983
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-101-5/+0
| | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 358135
* Promote more debug-only assertions to regular assertions.Adrian Prantl2019-03-071-1/+1
| | | | llvm-svn: 355569
* Replace 'ap' with 'up' suffix in variable names. (NFC)Jonas Devlieghere2019-02-131-5/+5
| | | | | | | | | | | | | | | | | The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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. llvm-svn: 351636
* Reflow paragraphs in comments.Adrian Prantl2018-04-301-44/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
* Fix a problem with line tables & .o files that start with code with no line ↵Jim Ingham2017-03-201-0/+8
| | | | | | | | | | | table entries. If you have code before the first line table entry when debugging with .o files on macOS, the LineTable entry search code was assigning all that code to the first line table entry. Don't do that. <rdar://problem/31095765> llvm-svn: 298289
* Move classes from Core -> Utility.Zachary Turner2017-02-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
* Fix more unused variable warnings when asserts are disabled.Hafiz Abid Qadeer2017-01-201-0/+1
| | | | llvm-svn: 292598
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-536/+464
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* Typo corrections identified by codespellEd Maste2016-07-191-1/+1
| | | | | | | | | Submitted by giffunip@yahoo.com; I fixed a couple of nearby errors and incorrect changes in the patch. llvm.org/pr27634 llvm-svn: 275983
* Keep original source path and mapped path in LineEntryTed Woodward2016-05-111-2/+3
| | | | | | | | | | | | | | | | | Summary: The "file" variable in a LineEntry was mapped using target.source-map, except when stepping through inlined code. This patch adds a new variable to LineEntry, "original_file", that contains the original file from the debug info. "file" will continue to (possibly) be mapped. Some code has been changed to use "original_file". This is code dealing with symbols. Code dealing with source files will still use "file". Reviewers, please confirm that these particular changes are correct. Tests run on Ubuntu 12.04 show no regression. Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20135 llvm-svn: 269250
* Fix dwarf sequence insertionsStephane Sezer2016-01-081-0/+7
| | | | | | | | | | | | | | | | | | | | | | Summary: If two dwarf sequences begin with entries that have identical addresses, it is possible for the comparator to order the first entry of the new sequence between the first and second entries of the existing sequence. This will result in an attempted insertion of the second sequence inside of the first sequence, which is invalid. Ensure that insertions only occur in between existing sequences. Reviewers: andrew.w.kaylor, clayborg Subscribers: sas, lldb-commits Differential Revision: http://reviews.llvm.org/D15979 Change by Francis Ricci <fjricci@fb.com> llvm-svn: 257132
* Fix prologue end handling when code compiled by gccTamas Berghammer2015-09-161-0/+10
| | | | | | | | | | | | | | | | | GCC don't use the is_prologue_end flag to mark the first instruction after the prologue. Instead of it it is issuing a line table entry for the first instruction of the prologue and one for the first instruction after the prologue. If the size of the prologue is 0 instruction then the 2 line entry will have the same file address. We remove these duplicates entries as they are violating the dwarf spec and can cause confusion in the debugger. To prevent the lost of information about the end of prologue we should set the prologue end flag for the line entries what are representing more then 1 entry. Differential revision: http://reviews.llvm.org/D12757 llvm-svn: 247788
* Fix typos.Bruce Mitchener2015-07-221-2/+2
| | | | | | | | | | | | Summary: Fix a bunch of typos. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11386 llvm-svn: 242856
* Fixed a problem where we might omit some breakpoints when using DWARF in .o ↵Greg Clayton2015-02-101-2/+1
| | | | | | | | | | files. The problem occurred when we had incorrect address ranges in the debug map that included the padding between functions causing the end address of a line table entry to fall into an inlinked (next function) address range. <rdar://problem/19721144> llvm-svn: 228707
* Remove dead store.Jason Molenda2014-10-161-1/+0
| | | | | | clang static analyzer fixit. llvm-svn: 219905
* Don't allow multiple line entries with the same address to exist sequentially.Greg Clayton2014-06-181-1/+11
| | | | | | The compiler, when JIT'ing code, can emit illegal DWARF line tables (address is line table sequences must increase). This changes fixes that issue by replacing previous line entries whose start address is the same with the new line entry to avoid having multiple line entries with the same address. Since the address range of lines entries is determined by the delta between the current and next line entry, this shouldn't cause any issues. llvm-svn: 211212
* Switch NULL to C++11 nullptr in source/Symbol and source/UtilityEd Maste2014-04-201-9/+9
| | | | | | Patch by Robert Matusewicz llvm-svn: 206713
* 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-1/+1
| | | | | | | | 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/13413693>Greg Clayton2013-03-141-2/+2
| | | | | | Fixed a crasher in the new DWARF in .o files line table linking function where "back()" could end up being called on an empty std::vector. llvm-svn: 177082
* <rdar://problem/13362109>Greg Clayton2013-03-061-15/+42
| | | | | | LLDB was not parsing line tables correctly for DWARF in .o files after recent debug map changes. This has now been fixed. llvm-svn: 176592
* <rdar://problem/13338643>Greg Clayton2013-03-041-139/+165
| | | | | | | | | | | | | | | | DWARF with .o files now uses 40-60% less memory! Big fixes include: - Change line table internal representation to contain "file addresses". Since each line table is owned by a compile unit that is owned by a module, it makes address translation into lldb_private::Address easy to do when needed. - Removed linked address members/methods from lldb_private::Section and lldb_private::Address - lldb_private::LineTable can now relink itself using a FileRangeMap to make it easier to re-link line tables in the future - Added ObjectFile::ClearSymtab() so that we can get rid of the object file symbol tables after we parse them once since they are not needed and kept memory allocated for no reason - Moved the m_sections_ap (std::auto_ptr to section list) and m_symtab_ap (std::auto_ptr to the lldb_private::Symtab) out of each of the ObjectFile subclasses and put it into lldb_private::ObjectFile. - Changed how the debug map is parsed and stored to be able to: - Lazily parse the debug map for each object file - not require the address map for a .o file until debug information is linked for a .o file llvm-svn: 176454
* Handle the case of unordered sequences in a DWARF line table.Andrew Kaylor2013-01-041-28/+74
| | | | llvm-svn: 171548
* Allow LLDB to work with dSYM files that have a DWARF compile unit with ↵Greg Clayton2012-12-121-0/+37
| | | | | | nothing else to support clang's new -gline-tables-only mode of compiling. llvm-svn: 169994
* <rdar://problem/11149427>Greg Clayton2012-03-291-2/+2
| | | | | | Line tables when using DWARF in .o files can be wrong when two entries get moved around by the compiler. This was due to incorrect logic in the line entry comparison operator. llvm-svn: 153685
* <rdar://problem/11078937>Greg Clayton2012-03-201-1/+3
| | | | | | LLDB can match incorrect line table entries when an address is between two valid line entries (in the gap between the valid debug info), now it doesn't! llvm-svn: 153077
* <rdar://problem/10103468>Greg Clayton2012-02-241-11/+15
| | | | | | | | | | | | | | | | | | | | | | | | | I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address objects in breakpoint locations that had lldb_private::Section pointers into modules that had been removed or replaced. This also let to grabbing stale modules from those sections. So I needed to thread harded the Address, Section and related objects. To do this I modified the ModuleChild class to now require a ModuleSP on initialization so that a weak reference can created. I also changed all places that were handing out "Section *" to have them hand out SectionSP. All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild so all of the find plug-in, static creation function and constructors now require ModuleSP references instead of Module *. Address objects now have weak references to their sections which can safely go stale when a module gets destructed. This checkin doesn't complete the "target symfile add" command, but it does get us a lot clioser to being able to do such things without a high risk of crashing or memory corruption. llvm-svn: 151336
* Added a new option to the "source list" command that allows us to see whereGreg Clayton2011-04-191-0/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | line tables specify breakpoints can be set in the source. When dumping the source, the number of breakpoints that can be set on a source line are shown as a prefix: (lldb) source list -f test.c -l1 -c222 -b 1 #include <stdio.h> 2 #include <sys/fcntl.h> 3 #include <unistd.h> 4 int 5 sleep_loop (const int num_secs) [2] 6 { 7 int i; [1] 8 for (i=0; i<num_secs; ++i) 9 { [1] 10 printf("%d of %i - sleep(1);\n", i, num_secs); [1] 11 sleep(1); 12 } 13 return 0; [1] 14 } 15 16 int 17 main (int argc, char const* argv[]) [1] 18 { [1] 19 printf("Process: %i\n\n", getpid()); [1] 20 puts("Press any key to continue..."); getchar(); [1] 21 sleep_loop (20); 22 return 12; [1] 23 } Above we can see there are two breakpoints for line 6 and one breakpoint for lines 8, 10, 11, 14, 18, 19, 20, 21 and 23. All other lines have no line table entries for them. This helps visualize the data provided in the debug information without having to manually dump all line tables. It also includes all inline breakpoint that may result for a given file which can also be very handy to see. llvm-svn: 129747
* Line tables were trying to be too clever and only use 24 bits for a lineGreg Clayton2010-12-191-8/+0
| | | | | | | | table offset where the offset is within a section. Increased the section offset for line table entries to be 32 bits (from 24 bits), giving each section a 4G offset, and increased the section index to 32 bits (from 8 bits). llvm-svn: 122200
* Moved the section load list up into the target so we can use the targetGreg Clayton2010-09-141-4/+4
| | | | | | to symbolicate things without the need for a valid process subclass. llvm-svn: 113895
* Looking at some of the test suite failures in DWARF in .o files with theGreg Clayton2010-09-141-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | debug map showed that the location lists in the .o files needed some refactoring in order to work. The case that was failing was where a function that was in the "__TEXT.__textcoal_nt" in the .o file, and in the "__TEXT.__text" section in the main executable. This made symbol lookup fail due to the way we were finding a real address in the debug map which was by finding the section that the function was in in the .o file and trying to find this in the main executable. Now the section list supports finding a linked address in a section or any child sections. After fixing this, we ran into issue that were due to DWARF and how it represents locations lists. DWARF makes a list of address ranges and expressions that go along with those address ranges. The location addresses are expressed in terms of a compile unit address + offset. This works fine as long as nothing moves around. When stuff moves around and offsets change between the remapped compile unit base address and the new function address, then we can run into trouble. To deal with this, we now store supply a location list slide amount to any location list expressions that will allow us to make the location list addresses into zero based offsets from the object that owns the location list (always a function in our case). With these fixes we can now re-link random address ranges inside the debugger for use with our DWARF + debug map, incremental linking, and more. Another issue that arose when doing the DWARF in the .o files was that GCC 4.2 emits a ".debug_aranges" that only mentions functions that are externally visible. This makes .debug_aranges useless to us and we now generate a real address range lookup table in the DWARF parser at the same time as we index the name tables (that are needed because .debug_pubnames is just as useless). llvm-gcc doesn't generate a .debug_aranges section, though this could be fixed, we aren't going to rely upon it. Renamed a bunch of "UINT_MAX" to "UINT32_MAX". llvm-svn: 113829
* Bug #: 8408441Greg Clayton2010-09-121-0/+58
| | | | | | | | Fixed an issue where LLDB would fail to set a breakpoint by file and line if the DWARF line table has multiple file entries in the support files for a source file. llvm-svn: 113721
* Fixed an issue with looking up line table entries by address where internalGreg Clayton2010-07-061-11/+39
| | | | | | | | | line table entries that were termination entries (ones that define the bounds of the previous entry) could be found when looking up line table entries. We now properly skip these termination entries and check the next entry to try for a match. llvm-svn: 107729
* Added function name types to allow us to set breakpoints by name moreGreg Clayton2010-06-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | intelligently. The four name types we currently have are: eFunctionNameTypeFull = (1 << 1), // The function name. // For C this is the same as just the name of the function // For C++ this is the demangled version of the mangled name. // For ObjC this is the full function signature with the + or // - and the square brackets and the class and selector eFunctionNameTypeBase = (1 << 2), // The function name only, no namespaces or arguments and no class // methods or selectors will be searched. eFunctionNameTypeMethod = (1 << 3), // Find function by method name (C++) with no namespace or arguments eFunctionNameTypeSelector = (1 << 4) // Find function by selector name (ObjC) names this allows much more flexibility when setting breakoints: (lldb) breakpoint set --name main --basename (lldb) breakpoint set --name main --fullname (lldb) breakpoint set --name main --method (lldb) breakpoint set --name main --selector The default: (lldb) breakpoint set --name main will inspect the name "main" and look for any parens, or if the name starts with "-[" or "+[" and if any are found then a full name search will happen. Else a basename search will be the default. Fixed some command option structures so not all options are required when they shouldn't be. Cleaned up the breakpoint output summary. Made the "image lookup --address <addr>" output much more verbose so it shows all the important symbol context results. Added a GetDescription method to many of the SymbolContext objects for the more verbose output. llvm-svn: 107075
* Minor warning/error fixes.Eli Friedman2010-06-091-2/+3
| | | | llvm-svn: 105718
* Initial checkin of lldb code from internal Apple repo.Chris Lattner2010-06-081-0/+332
llvm-svn: 105619
OpenPOWER on IntegriCloud