[Dwarf-Discuss] modeling different address spaces

[David Blaikie]

On Thu, Jul 16, 2020 at 12:55 PM Michael Eager <eager at eagercon.com> wrote:

> On 7/16/20 11:51 AM, David Blaikie wrote:
> >
> >
> > On Thu, Jul 16, 2020 at 11:41 AM Robinson, Paul via Dwarf-Discuss
> >     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.
>
> As Paul said, DW_AT_segment is not generally needed to describe a
> Harvard architecture.
>
> > 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...
>
> On some (many?) architectures, data and code may be interspersed, for
> example, to place constant data with the executable text.
>
> DIEs can have different DW_AT_segments.
>
> Entries in .debug_aranges have segment, offset, and length.
>
> What is the use case for having multiple segments in a range list?
>

The same as the use case for varying the segment per high_pc, I'd have
thought - if code is in different segments. But if you're suggesting the
only valid use of DW_AT_segment is to always have it have the same value on
any DIE with ranges/low/high pc, and always the same (but possibly a
distinct value) for DW_AT_location-having DIEs, fair enough. The spec
doesn't seem to say that, though. It suggests it could vary more than that?

Guess for things like the original poster's case (though, like Paul, I've
not read AMD's proposal here) - GPU code with a separate address space from
CPU code, for instance.


> > (& 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))
>
> As Paul mentioned, that's not what the spec says.
>
> > & 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?
>
> Location lists contain segment, offset, and length.
>

I don't see any mention of segment in 2.6.2 - or do you mean base address
selection entries? Yeah, you could use those (& can use them even in an
unsegmented situation) & can use those in debug_ranges too. So, again, if
the notion is that everything's really in a contiguous address space &
segment selectors are a convenience - that lines up here.

loc/range and loclist/rnglist seem to use the same encoding for their
address ranges (loc/loclist just have the extra location tacked on after
the address range description) - as far as I've read.


>
> --
> Michael Eager
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20200716/32e1fa0f/attachment.html>