[Dwarf-Discuss] modeling different address spaces

[Michael Eager]

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.

> Certainly x86 does not fall into that "truly distinct segments" category, at
> least not in modern times.  The segment registers there (fs & gs, for example)
> are an indirect way of specifying a base address within the flat address space.
> They usually end up being used for thread-specific data structures where each
> thread has a different segment selector which implies a different base address.
> And it requires a syscall to interact with the base addresses, at least on
> Linux.  The other segment registers (cs, ds, ss) are set-and-forget by the OS
> typically.

As soon as you mention segment registers, you move from the static 
description of the memory image to the dynamic description of the 
execution.  DW_AT_segment is a static description of memory layout.  The 
computations in a DWARF expression (which may reference a segment 
register) are only relevant when looking at an executing program (or a 
memory dump) and you have a PC context.

The Intel terminology describing the static memory addressing as 
segments with the dynamic segment registers leads to this confusion.

> The CUDA architecture is an interesting case.  It doesn't use DW_AT_segment at
> all.  But it does use the DW_AT_address_class attribute to specify CUDA segments
> (e.g. Global, Local, Shared, among many others) for variables and/or types.  So
> it's fairly fine-grained.  You can, for example, have a shared pointer to a
> global pointer to a local integer, and the DW_AT_address_class attribute can
> convey that.
> 
> Some of those CUDA segments are for radically different sorts of memory
> (e.g. very low latency Shared memory vs. high latency Global memory).  But other
> distinctions seem more gratuitous (e.g. Param vs. Global memory).  I assume that
> there's a CUDA under-the-hood mapping of many of the segments to regions of a
> flat Global address space in there, but the CUDA architectures & drivers
> deliberately hide that mapping.  So effectively you end up with all the segments
> being distinct, as far as a debugger can tell.

CUDA address spaces or a DSP with multiple distinct address spaces are 
what would conventionally be described as segmented memory.  I think 
that using the DW_AT_address_space would be reasonable.

> 
> On Thu, Jul 16, 2020 at 09:23:51AM +0000, Dwarf Discussion wrote:
>>     Hello,
>>
>>
>>
>>     What would be the recommended way to model variables that are allocated to
>>     different address spaces?
>>
>>
>>
>>     I found DW_OPT_xderef for dereferencing address-space qualified pointers
>>     but the resulting memory location description wouldn't have an
>>     address-space qualifier.
>>
>>
>>
>>     I found DW_AT_address_class, which allows attaching an integer, which
>>     could represent the address-space.  This sounds pretty close.  I'm a bit
>>     thrown off by the example, though.
>>
>>
>>
>>     Thanks,
>>
>>     Markus.
>>
> 

-- 
Michael Eager