[Dwarf-Discuss] modeling different address spaces

[David Blaikie]

On Thu, Jul 16, 2020 at 11:41 AM Robinson, Paul via Dwarf-Discuss <
dwarf-discuss at lists.dwarfstd.org> wrote:

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

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 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/20200716/2d4e0c9b/attachment-0001.html>