[Dwarf-Discuss] Segment selectors for Harvard architectures

[David Blaikie]

On Sun, Mar 29, 2020 at 2:56 PM Cary Coutant <ccoutant at gmail.com> wrote:

> > 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.


It seems to me that it's important that these sort of lookup tables aren't
left up to quality of implementation, though (see the work that went into
ensuring debug_names has a clear list of contents, the problems when
debug_pubnames did not (that lead to debug_gnu_pubnames), etc - consumers
and producers aren't necessarily paired & having an authoritative list of
things that must be in these sections seems the only way a producer should
rely on them/their contents, not based on which producer produced it. Do
you find that's not the case? I'd like to better understand that.

So I'm looking for an authoritative "this is what DWARF requires of
producers and guarantees for consumers" kind of thing.

But sure, left up to implementation quality, I'd probably just remove them
and say "GCC does it this way & it's the defacto standard" & maybe suggest
the DWARF committee could rephrase this to make that explicit.


> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20200330/fd00b7e1/attachment.html>