FYI, Tony Tye and his team at AMD created a DWARF Proposal for heterogeneous debugging, which is generally useful but required to debug optimized code for GPUs. It directly addresses the issue of how to model different address spaces and makes location descriptions first-class objects that can be push onto the evaluation stack.
https://llvm.org/docs/AMDGPUDwarfProposalForHeterogeneousDebugging.html AFAIK, these changes will be made to LLVM and there is interest in adding to the DWARF standard eventually. Cheers, John D. On 2020-07-16 13:06, 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. > > 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. > > 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. > > 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. >> > -- > Todd Allen > Concurrent Real-Time > _______________________________________________ > Dwarf-Discuss mailing list > Dwarf-Discuss@lists.dwarfstd.org > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org > > > CAUTION: This email originated from outside of the organization. Do not click > on links or open attachments unless you recognize the sender and know the > content is safe. This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. _______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
