[Dwarf-Discuss] Segment selectors for Harvard architectures

[David Blaikie]

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")

On Thu, Mar 19, 2020 at 11:05 AM Robinson, Paul via Dwarf-Discuss <
dwarf-discuss at lists.dwarfstd.org> wrote:

> This recently came up in the LLVM project.  Harvard architectures
> put code and data into separate address spaces, but those spaces
> are not explicit; instructions that load/store memory implicitly
> use the data space, while things like taking a function address or
> doing indirect branches will implicitly use the code space.  This
> doubles the effective size of memory without consuming an address
> bit, as well as having other secondary benefits like not allowing
> self-modifying code.
>
> Nearly all of the DWARF information does not need to distinguish
> between code and address spaces, because it's easy to derive that
> from context.  Addresses in the line table or a range list will be
> code addresses; in .debug_info, addresses of code elements will be
> code addresses, while variables will be data addresses. And so on.
>
> This only seems to break down in the .debug_aranges section, which
> records both data and code addresses without any context to let a
> consumer know which is what.  In a flat-address architecture, no
> distinction is needed; in a segmented architecture, there will be
> a segment selector as part of any address, and that includes the
> .debug_aranges section.  What about for Harvard architectures?
>
> What I suggested in the LLVM project is that .debug_aranges would
> have a 1-byte segment selector and use some trivial scheme such as
> 0=code, 1=data to distinguish what kind of address it is.  Other
> DWARF sections wouldn't need a selector because they can all use
> context to figure it out; this avoids the size overhead of using
> segment selectors everywhere else.
>
> Pavel Labath pointed out that this seems inconsistent and might
> make consumers unhappy; segment selectors are described as a
> characteristic of the target architecture, so having them in one
> place and not others might look suspicious.  IMO it's a reasonable
> "permissive" use of the existing DWARF structures, but it seemed
> worth asking here.
>
> Does this (segment selector only in .debug_aranges) sound okay?
> Should there be non-normative text or a wiki description of this?
> Do we want to codify the 0=code 1=data use of segment selectors
> for all Harvard architectures (that don't otherwise have explicit
> segements) so that this doesn't have to be set by ABI committees?
>
> I'm willing to write up whatever needs writing up, either as a
> proposal or as a wiki entry.
>
> Thanks,
> --paulr
>
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20200323/c23b43de/attachment.html>