[PATCH] D31424: [ELF] - Use relocated content when generating .gdb_index

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 28 09:25:05 PDT 2017


dblaikie added inline comments.


================
Comment at: ELF/SyntheticSections.cpp:1739-1740
+  // consists of a 0 for the beginning address offset and a 0 for the ending
+  // address offset. We assume here that whole section data starting from offset
+  // is a range, terminated with null entry.
+  if (Optional<uint64_t> Offset = toSectionOffset(Die.find(DW_AT_ranges))) {
----------------
I don't understand what assumption you're describing.

Oh, because relocations haven't been performed, nor handled at all - it's not possible to tell where the address ranges end, so you're providing an overestimate here? That's a bit subtle and the function name should at least mention that I would think (& the function that calls this one too)

Is there any penalty to this overestimate in how the gdb_index is created? Does a larger sized record need to be used to handle a maximum that may never be needed?

[looking at the implementation, it seems there is a penalty for overestimate - a table is reserved for that many address ranges, right? so much of that table may go unused if this is a significant overestimate (though that probably only happens if someone uses ld -r or, perhaps more likely: LTO)]

I wouldn't imagine it'd be too hard to look at enough relocation data (essentially parse the relocations applicable to debug_ranges and look for holes (bytes that don't have relocations for them) - those are the ends of range lists - you wouldn't need to apply any relocations or examine their addends, etc, only their offsets)




https://reviews.llvm.org/D31424





More information about the llvm-commits mailing list