[Dwarf-Discuss] Segment selectors for Harvard architectures

[Cary Coutant]

> 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