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
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
