[Dwarf-Discuss] modeling different address spaces

[Robinson, Paul]

(resending, this time without dropping the list from the cc: grump grump)

> -----Original Message-----
> From: Dwarf-Discuss <dwarf-discuss-bounces at lists.dwarfstd.org> On Behalf
> Of Michael Eager via Dwarf-Discuss
> Sent: Thursday, July 16, 2020 2:12 PM
> To: todd.allen at concurrent-rt.com; Metzger, Markus T
> <markus.t.metzger at intel.com>
> Cc: dwarf-discuss at lists.dwarfstd.org
> Subject: Re: [Dwarf-Discuss] modeling different address spaces
> 
> On 7/16/20 10:06 AM, Todd Allen via Dwarf-Discuss wrote:
> > Markus, Michael, David, Xing,
> >
> > I always assumed that the segment support in DWARF was meant to be more
> general,
> > and support architectures where there was no single flat memory, and so
> the
> > segments were necessary for memory accesses.  I personally have not
> dealt with
> > any architectures where DW_AT_segment came into play, though.
> 
> It is phrased in a way to make it less architecturally specific.  That's
> in keeping with our desire to prevent DWARF from including architecture
> specific specifications.  For example, we don't want to say "on ARM do
> this" but on "MIPS do that".  DWARF doesn't specify how the translation
> from segmented to linear addresses is done.

The example that most often comes up is Harvard architectures.  As it
happens, I think it's nearly always obvious from context whether a given
address is data-segment or code-segment.  The only time it's not, that I'm
aware of, is in the .debug_aranges section, where addresses are associated
with compile-units without any indication of whether they are code or data
addresses.  I've heard arguments that .debug_aranges should only have code
addresses in it, but I don't think that's what the spec says.
--paulr