(resending, this time without dropping the list from the cc: grump grump) > -----Original Message----- > From: Dwarf-Discuss <dwarf-discuss-boun...@lists.dwarfstd.org> On Behalf > Of Michael Eager via Dwarf-Discuss > Sent: Thursday, July 16, 2020 2:12 PM > To: todd.al...@concurrent-rt.com; Metzger, Markus T > <markus.t.metz...@intel.com> > Cc: dwarf-discuss@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 _______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
