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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Stephane Sezer