> Not to derail this thread, but another thing that might be worth checking is: > should debug_aranges include non-code addresses. GCC's don't, Clang's do. > Sounds like Clang's correct, but GCC is sort of the defacto standard DWARF > producer, so might be worth getting an authoritative statement/clarified > wording here. (especially since it's intended for lookup, so it's important > what is/isn't included, much like debug_names - not so open to leaving it up > to "quality of implementation")
I think it comes down to what end-user scenarios you want to support that would require a fast lookup table for data addresses. The .debug_aranges section supports scenarios like "the program is stopped at (or a backtrace contains) this random PC; what can you tell me about that?" I don't know if you need to support any such scenarios involving data addresses. Given that GCC/GDB haven't needed data addresses in the table, it seems like so far either (a) they have no need to support such scenarios, or (b) they've found a way around the lack of fast-lookup info (perhaps by guessing that any data address is likely to be associated with the current compilation unit). If you can't find any real need for it, I'd suggest following GCC's lead and forget about them, obviating the need for using the segment selector. If you do still find a need for fast lookup of data addresses, a segment selector seems like a waste of space, though I don't really have a problem with the idea of using it there and nowhere else. I'd be tempted to use a completely separate table, though -- say .debug_dranges -- as an extension. -cary _______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
