On Thu, Jul 16, 2020 at 11:41 AM Robinson, Paul via Dwarf-Discuss < dwarf-discuss@lists.dwarfstd.org> wrote:
> (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. > Curious - the spec doesn't seem to read that way to me - and if that were its goal, it seems like DW_AT_segment wouldn't really be needed. DW_AT_locations would always be data, DW_AT_high/low/ranges would always be code, etc? The spec... specifically says DW_AT_segment applies to high/low/ranges, and describes a parent-DIE delegation scheme that seems to suggest that some DIEs could have one segment, and others could have a different segment - but no way for ranges to have different segments in different parts of the same range list, which seems to be at odds with the ability to vary segment across a DIE tree - you couldn't put a ranges at the top of such a variegated tree... (& yeah, the arange situation crossed my mind too - on both counts you noted (that it needs it, but that it may not - because some interpretations suggest it should only contain code addresses anyway)) & not sure how any of this resolves the "but debug_addr has segment selectors" nor "what's the point of segment selector size in debug_rnglists, debug_loclists, and debug_line" - none of those sections seem to contain segment selectors, so why do their headers describe the size of such a thing? > --paulr > > _______________________________________________ > Dwarf-Discuss mailing list > Dwarf-Discuss@lists.dwarfstd.org > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org >
_______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
