[Dwarf-Discuss] modeling different address spaces

[Michael Eager]

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?

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

-- 
Michael Eager