The Symtab has an array of symbol file addresses and sizes for address-to-symbol lookups, created in Symtab::InitAddressIndexes. The Symtab has a vector of symbol (m_symbols) and a parallel vector of Range entries (m_file_addr_to_index - the index being an index into m_symbols). Once the m_symbols have been filled in, it makes a pass over them and creates the m_file_addr_to_index entries. Then it does additional passes to fill in the sizes of the Range entries based on the other symbol start addresses.
I'm working on a problem in an environment where the sections of a file are noncontiguous in memory - so we can have a gap of hundreds of megabytes between the sections, and the last symbol in the first section gets a 400MB size. If the unwinder (or one of the fallback unwind methods) happens to come up with an address in that 400MB gap, lldb will try to disassemble that entire section, thinking it is a function.
Before this patch, InitAddressIndexes would create the m_file_addr_to_index array, then set sizes based on the next symbol, then use the last section's end address to set the last symbol(s) in the array.
In this patch, I'm using the smaller of the containing section end OR the next symbol's address to determine the symbol's size. Looking up the section for each symbol would be expensive, so I make a local RangeVector with all of the section address/sizes before I loop over the entries. RangeVector::Sort sorts by start address and then by size so we'll get the smallest containing section for a given lookup.
You want to only add sections that don't have children. On MacOSX we have:
__TEXT [0x1000-0x2000)
If you have all of these in the mix you will have a non deterministic sort since TEXT and text will compare to the same thing. Object files are also tricky because they have only one LC_SEGMENT with a bunch of sections and the ObjectFileMachO will actually make segments from the segname and sectname and they will have overlapping address ranges. Checking out a .o file from a recent build:
Now if we look at what ObjectFileMachO does:
Note that TEXT and DWARF overlap. That will probably cause problems. So the fix is to only add sections that don't have children.