Re: [Dwarf-Discuss] modeling different address spaces

2020-08-07 Thread David Blaikie via Dwarf-Discuss
On Fri, Aug 7, 2020 at 9:43 AM Pedro Alves via Dwarf-Discuss
 wrote:
>
> Hi there!
>
> On 7/31/20 1:17 AM, Tye, Tony via Dwarf-Discuss wrote:
> > For optimized code involving multiple address spaces it is possible to run 
> > into cases where the location of a source language variable requires 
> > multiple address spaces. For example, a source variable may be optimized 
> > and different pieces may be in different places including memory of 
> > multiple address spaces, registers, etc. Describing this situation with a 
> > DW_AT_address_class on a source language variable is not possible as it 
> > provides a single address space that applies to the variable as a whole. 
> > The concept of "address space" is not available on the expression stack 
> > where a composite location description is created.
> >
> >
> >
> > Instead, making address space a property of memory location descriptions 
> > and making location descriptions a first-class concept on the expression 
> > stack solves the problem in a general way and leads to other nice 
> > properties.
>
> I am interesting in re-reading the document describing your changes, but the
> url that was pasted on the list before:
>
>  https://llvm.org/docs/AMDGPUDwarfProposalForHeterogeneousDebugging.html

https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html

>
> is now returning "Not Found".  Did the document move somewhere else?
>
> Pedro Alves
> ___
> Dwarf-Discuss mailing list
> Dwarf-Discuss@lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] modeling different address spaces

2020-08-07 Thread Pedro Alves via Dwarf-Discuss
Hi there!

On 7/31/20 1:17 AM, Tye, Tony via Dwarf-Discuss wrote:
> For optimized code involving multiple address spaces it is possible to run 
> into cases where the location of a source language variable requires multiple 
> address spaces. For example, a source variable may be optimized and different 
> pieces may be in different places including memory of multiple address 
> spaces, registers, etc. Describing this situation with a DW_AT_address_class 
> on a source language variable is not possible as it provides a single address 
> space that applies to the variable as a whole. The concept of "address space" 
> is not available on the expression stack where a composite location 
> description is created.
> 
>  
> 
> Instead, making address space a property of memory location descriptions and 
> making location descriptions a first-class concept on the expression stack 
> solves the problem in a general way and leads to other nice properties.

I am interesting in re-reading the document describing your changes, but the
url that was pasted on the list before:

 https://llvm.org/docs/AMDGPUDwarfProposalForHeterogeneousDebugging.html

is now returning "Not Found".  Did the document move somewhere else?

Pedro Alves
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] modeling different address spaces

2020-07-31 Thread Tye, Tony via Dwarf-Discuss
A compiler may promote part of a variable to a scratch pad memory address space.

Thanks,
-Tony Tye

-Original Message-
From: Michael Eager

On 7/30/20 5:17 PM, Tye, Tony via Dwarf-Discuss wrote:
> For optimized code involving multiple address spaces it is possible to 
> run into cases where the location of a source language variable 
> requires multiple address spaces. For example, a source variable may 
> be optimized and different pieces may be in different places including 
> memory of multiple address spaces, registers, etc.

Can you explain this more?

DWARF handles the situation where part of a variable is in memory and part in a 
register or in multiple registers.  When would you have a variable which was in 
multiple address spaces?

--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] modeling different address spaces

2020-07-31 Thread Metzger, Markus T via Dwarf-Discuss
Hello Michael,

Sorry for the late reply.  I found the email in the spam folder today.

> >>> We'd also want an unbounded piece operator to describe partially
> registerized
> >>> unbounded arrays, but I have not worked that out in detail, yet, and 
> >>> we're a
> bit
> >>> farther away from an implementation.
> >>
> >> Can you describe this more?
> >
> > Consider a large array kept in memory and a for loop iterating over the 
> > array.
> If that
> > loop gets vectorized, compilers would load a portion of the array into 
> > registers
> at the
> > beginning of the loop body, operate on the registers, and write them back at
> the end
> > of the loop body.
> >
> > The entire array can be split into three pieces:
> > - elements that have already been processed: in memory
> > - elements that are currently being processed: in registers
> > - elements that will be processed in future iterations: in memory
> >
> > For unbounded arrays, the size of the third piece is not known.
> 
> When would you need to know the third piece?
> 
> How is this different from a non-vector processor doing an optimized
> string operation, loading 4 characters into a register at a time?  If
> the string is nul-terminated, the string length might be unknown.

I don't think that this is different from the use-case I sketched above.  We 
wouldn't
even need to load a sequence of elements.  Loading a single element would 
produce
the same scenario.

Can this be described in DWARF today?

Markus.

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Gary Kershaw
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] modeling different address spaces

2020-07-31 Thread Frank Ch. Eigler via Dwarf-Discuss
Hi -

> Can you explain this more?
> 
> DWARF handles the situation where part of a variable is in memory and part
> in a register or in multiple registers.  When would you have a variable
> which was in multiple address spaces?

Remember the "how can a debugger WRITE safely to variables" discussion
last year?  A variable may reside in some unusual memory segment, AND
may have been loaded into a register, AND maybe even spilled to the
normal stack temporarily.  Could be three different address spaces
valid for the same variable at the same PC address.  (And a debugger
that needs to update the value would need to find them all.)

- FChE

___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] modeling different address spaces

2020-07-30 Thread Michael Eager via Dwarf-Discuss

On 7/30/20 5:17 PM, Tye, Tony via Dwarf-Discuss wrote:
For optimized code involving multiple address spaces it is possible to 
run into cases where the location of a source language variable requires 
multiple address spaces. For example, a source variable may be optimized 
and different pieces may be in different places including memory of 
multiple address spaces, registers, etc. 


Can you explain this more?

DWARF handles the situation where part of a variable is in memory and 
part in a register or in multiple registers.  When would you have a 
variable which was in multiple address spaces?




--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] modeling different address spaces

2020-07-30 Thread Tye, Tony via Dwarf-Discuss
For optimized code involving multiple address spaces it is possible to run into 
cases where the location of a source language variable requires multiple 
address spaces. For example, a source variable may be optimized and different 
pieces may be in different places including memory of multiple address spaces, 
registers, etc. Describing this situation with a DW_AT_address_class on a 
source language variable is not possible as it provides a single address space 
that applies to the variable as a whole. The concept of "address space" is not 
available on the expression stack where a composite location description is 
created.



Instead, making address space a property of memory location descriptions and 
making location descriptions a first-class concept on the expression stack 
solves the problem in a general way and leads to other nice properties.



Thanks,

-Tony

___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] modeling different address spaces

2020-07-20 Thread Michael Eager via Dwarf-Discuss

On 7/20/20 8:24 AM, Metzger, Markus T wrote:

Hello Michael,

I tried submitting the proposal via the public comment function but I'm not sure
whether I succeeded.  When I clicked on "Submit Comment" nothing happened.
I have not filled out the Section and Page fields as the proposal covers 
multiple
sections on multiple pages.  I did not get any error.  I'm attaching the 
proposal.



Thanks for resubmitting.  This is proposal 200720.1:
http://dwarfstd.org/ShowIssue.php?issue=200720.1

--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] modeling different address spaces

2020-07-20 Thread Michael Eager via Dwarf-Discuss

On 7/20/20 8:24 AM, Metzger, Markus T wrote:

Hello Michael,


We'd also want an unbounded piece operator to describe partially registerized
unbounded arrays, but I have not worked that out in detail, yet, and we're a bit
farther away from an implementation.


Can you describe this more?


Consider a large array kept in memory and a for loop iterating over the array.  
If that
loop gets vectorized, compilers would load a portion of the array into 
registers at the
beginning of the loop body, operate on the registers, and write them back at 
the end
of the loop body.

The entire array can be split into three pieces:
- elements that have already been processed: in memory
- elements that are currently being processed: in registers
- elements that will be processed in future iterations: in memory

For unbounded arrays, the size of the third piece is not known.


When would you need to know the third piece?

How is this different from a non-vector processor doing an optimized 
string operation, loading 4 characters into a register at a time?  If 
the string is nul-terminated, the string length might be unknown.


--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] modeling different address spaces

2020-07-20 Thread Metzger, Markus T via Dwarf-Discuss
Hello Michael,

> > I have a write-up ready but wanted to wait until we have a public
> implementation.
> > Is that the right order?  Or would you rather want to review proposals right
> away.
> 
> I'm not sure what a SIMD lane is.  There are a number of architectures
> which support SIMD, such as the AVX extension in x86.  We try to
> describe functionality in generic terms as much as possible so that it
> can be used with a variety of architectures.
> 
> We'd be happy to see your proposal.  Often an implementation is a good
> proof of concept, but getting feedback on a design early in the process
> can be a guide to that implementation and avoids changes later.

I tried submitting the proposal via the public comment function but I'm not sure
whether I succeeded.  When I clicked on "Submit Comment" nothing happened.
I have not filled out the Section and Page fields as the proposal covers 
multiple
sections on multiple pages.  I did not get any error.  I'm attaching the 
proposal.

The proposal covers SIMD in general.  I have patches for GDB with a test case
using AVX.


> > We'd also want an unbounded piece operator to describe partially 
> > registerized
> > unbounded arrays, but I have not worked that out in detail, yet, and we're 
> > a bit
> > farther away from an implementation.
> 
> Can you describe this more?

Consider a large array kept in memory and a for loop iterating over the array.  
If that
loop gets vectorized, compilers would load a portion of the array into 
registers at the
beginning of the loop body, operate on the registers, and write them back at 
the end
of the loop body.

The entire array can be split into three pieces:
- elements that have already been processed: in memory
- elements that are currently being processed: in registers
- elements that will be processed in future iterations: in memory

For unbounded arrays, the size of the third piece is not known.

Regards,
Markus.

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Gary Kershaw
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
Implicitly vectorized code executes multiple instances of a source code loop or
of a source code kernel function simultaneously in a single sequence of
instructions operating on a vector of data elements (cf. SIMD: Single
Instruction Multiple Data).

The size of this vector is typically referred to as SIMD width or SIMD size.
Individual elements and their control flow are typically referred to as SIMD
lanes or SIMD channels.

The user has written the source code from the point of view of a single SIMD
lane.  The code was later vectorized by the compiler to execute multiple SIMD
lanes simultaneously.

Although SIMD code typically works on large vectors or matrices, the compiler is
free to temporarily reorganize the data, e.g. by registerizing some vector
elements, while leaving the rest of the vector in memory or by gathering a
particular structure field of a vector of structures in a register.

Further, the assignment of loop iterations or work items to SIMD lanes may be
done dynamically.

We thus cannot infer the relative location of data objects in SIMD code.

To be able to describe this, we propose the following DWARF extension to
describe the location of a variable as function of the SIMD lane.

===

Section 2.2, pg. 17-22.

Add the following entry to Table 2.2:

  ---
  DW_AT_simd_widthSIMD width of subroutine or
  lexical block
  ---


Section 3.3.5, pg. 79-80.

Add

A subprogram or inlined subroutine may have a `DW_AT_simd_width` attribute
whose value is the SIMD width of the code it contains.  A value of zero
means that the subroutine does not contain SIMD code.

If the attribute is not present, the SIMD width is inherited from the parent
DIE.

The SIMD width may be overwritten for nested subroutines or for lexical
blocks contained within that subroutine.


Section 3.5, pg. 92.

Add

A lexical block that contains SIMD code may have a `DW_AT_simd_width`
attribute whose value is the SIMD width of the code it contains.  A value of
zero means that the lexical block does not contain SIMD code.  This can be
used to mark non-SIMD blocks inside a SIMD subroutine.

If the attribute is not present, the SIMD width is inherited from the parent
DIE.

The SIMD width may be overwritten for lexical blocks nested within that
block.


Section 2.5.1.3, pg. 29-33.

Add

16. DW_OP_push_simd_lane

The DW_OP_push_simd_lane operation pushes the SIMD lane for which the
expression shall be evaluated.

The operation is only valid in the context of a lexical block for which
the SIMD width is known (see DW_AT_simd_width).

 

Re: [Dwarf-Discuss] modeling different address spaces

2020-07-20 Thread Michael Eager via Dwarf-Discuss

On 7/20/20 1:31 AM, Metzger, Markus T via Dwarf-Discuss wrote:

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.



Which example?



Table 2.7 "Example address class codes" on p. 48.  It uses DW_AT_address_class
to describe addressing modes.


We've muddled two related concepts, segmented addresses and address 
classes, into one description.  As recent discussion shows, maybe we 
should clarify this section.


DW_AT_segment describes how an address is constructed from a segment and 
offset.  The segment and offset are represented independently.


DW_AT_address_class is an attribute that tells the consumer how to 
interpret an address, without specifying any specific segment or address 
space.


AFAIK, only x86 uses DW_AT_segment.  I presume that it could also be 
used for architectures with multiple address spaces, but I'm not aware 
of any that do.  If anyone knows of another architecture using this 
attribute, I'd like to hear about it.


--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] modeling different address spaces

2020-07-20 Thread Metzger, Markus T via Dwarf-Discuss
Hello Todd,

> They use DW_AT_address_class with a CUDA-specific enum of address spaces,
> with
> values for things like: global memory, shared memory, const memory, etc.  They
> don't attach these attributes to subroutines, because all the code on that
> architecture is in a single "code" memory.  They do attach them to pointer
> types, as the DWARF spec describes.  They also attach them to variables,
> formals, etc.  That's a vendor extension (which I'd forgotten until I looked 
> it
> up again in the DWARF spec).  But an obvious one.  We might want to formalize 
> it
> at some point.
> 
> Anyway, these are the sorts of things we see:
> 
>DW_TAG_pointer_type
>   DW_AT_type  : ...
>   DW_AT_address_class : ptxGenericStorage
> 
>DW_TAG_variable
>   DW_AT_name  : myConstant
>   DW_AT_type  : ...
>   DW_AT_location  : ...
>   DW_AT_address_class : ptxConstStorage
> 
>DW_TAG_variable
>   DW_AT_abstract_origin : ...
>   DW_AT_location: ...
>   DW_AT_address_class   : ptxLocalStorage
> 
> I don't know your architecture, but I'd expect something similar to work for 
> any
> GPU with heterogeneous memories.

That looks good to me.  And I agree that it would be very nice if the extension 
to
attach this attribute to variables were formalized.

Thanks,
Markus.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Gary Kershaw
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] modeling different address spaces

2020-07-20 Thread Michael Eager via Dwarf-Discuss

On 7/20/20 1:43 AM, Metzger, Markus T via Dwarf-Discuss wrote:


I also have a small proposal for describing locations as function of the SIMD 
lane by
adding a DW_OP_push_simd_lane operator and introducing stack variants for piece
operators.
  
I have a write-up ready but wanted to wait until we have a public implementation.

Is that the right order?  Or would you rather want to review proposals right 
away.


I'm not sure what a SIMD lane is.  There are a number of architectures 
which support SIMD, such as the AVX extension in x86.  We try to 
describe functionality in generic terms as much as possible so that it 
can be used with a variety of architectures.


We'd be happy to see your proposal.  Often an implementation is a good 
proof of concept, but getting feedback on a design early in the process 
can be a guide to that implementation and avoids changes later.



We'd also want an unbounded piece operator to describe partially registerized
unbounded arrays, but I have not worked that out in detail, yet, and we're a bit
farther away from an implementation.


Can you describe this more?

--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] modeling different address spaces

2020-07-20 Thread Todd Allen via Dwarf-Discuss
Markus,

My experience with an architecture like this also is a GPU: the Nvidia CUDA
GPUs.  I don't work on nvcc.  I'm coming at this from the consumer side.  But
what I've observed:

They use DW_AT_address_class with a CUDA-specific enum of address spaces, with
values for things like: global memory, shared memory, const memory, etc.  They
don't attach these attributes to subroutines, because all the code on that
architecture is in a single "code" memory.  They do attach them to pointer
types, as the DWARF spec describes.  They also attach them to variables,
formals, etc.  That's a vendor extension (which I'd forgotten until I looked it
up again in the DWARF spec).  But an obvious one.  We might want to formalize it
at some point.

Anyway, these are the sorts of things we see:

   DW_TAG_pointer_type
  DW_AT_type  : ...
  DW_AT_address_class : ptxGenericStorage

   DW_TAG_variable
  DW_AT_name  : myConstant
  DW_AT_type  : ...
  DW_AT_location  : ...
  DW_AT_address_class : ptxConstStorage

   DW_TAG_variable
  DW_AT_abstract_origin : ...
  DW_AT_location: ...
  DW_AT_address_class   : ptxLocalStorage

I don't know your architecture, but I'd expect something similar to work for any
GPU with heterogeneous memories.

-- 
Todd Allen
Concurrent Real-Time

On Mon, Jul 20, 2020 at 08:31:53AM +, Dwarf Discussion wrote:
> Hello Michael,
> 
> > > What would be the recommended way to model variables that are allocated
> > > to different address spaces?
> > 
> > Can you describe the architecture a bit?
> 
> It's a GPU.  It uses a different address space for shared local memory.
> 
> 
> > > I found DW_OPT_xderef for dereferencing address-space qualified pointers
> > > but the resulting memory location description wouldn???t have an
> > > address-space qualifier.
> > 
> > DW_OPT_xderef translates from an architecturally defined memory
> > reference including an address space into a linear address space
> > (generic type).  DWARF doesn't support computations on address-space
> > qualified addresses, although using a typed stack, this could be an
> > extension.
> 
> I don't see a need for this, right now.  It should suffice to describe that an
> object lives in address-space A so the location expression yields an 
> A-address.
> 
> In another email you said: "
> 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.
> ".
> 
> I assume you mean DW_AT_address_class.  This should do the trick.  I just 
> wasn't
> sure if that's the intended use of that attribute.
> 
> 
> > > 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.
> > 
> > Which example?
> 
> Table 2.7 "Example address class codes" on p. 48.  It uses DW_AT_address_class
> to describe addressing modes.
> 
> Regards,
> Markus.
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Christin Eisenschmid, Gary Kershaw
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
> ___
> Dwarf-Discuss mailing list
> Dwarf-Discuss@lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] modeling different address spaces

2020-07-20 Thread Metzger, Markus T via Dwarf-Discuss
Hello Michael,

> 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.
> 
> As mentioned in the past, I would be pleased to see proposals submitted
> for these changes.

I also have a small proposal for describing locations as function of the SIMD 
lane by
adding a DW_OP_push_simd_lane operator and introducing stack variants for piece
operators.
 
I have a write-up ready but wanted to wait until we have a public 
implementation.
Is that the right order?  Or would you rather want to review proposals right 
away.

We'd also want an unbounded piece operator to describe partially registerized
unbounded arrays, but I have not worked that out in detail, yet, and we're a bit
farther away from an implementation.

Regards,
Markus.

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Gary Kershaw
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] modeling different address spaces

2020-07-20 Thread Metzger, Markus T via Dwarf-Discuss
Hello Michael,

> > What would be the recommended way to model variables that are allocated
> > to different address spaces?
> 
> Can you describe the architecture a bit?

It's a GPU.  It uses a different address space for shared local memory.


> > I found DW_OPT_xderef for dereferencing address-space qualified pointers
> > but the resulting memory location description wouldn’t have an
> > address-space qualifier.
> 
> DW_OPT_xderef translates from an architecturally defined memory
> reference including an address space into a linear address space
> (generic type).  DWARF doesn't support computations on address-space
> qualified addresses, although using a typed stack, this could be an
> extension.

I don't see a need for this, right now.  It should suffice to describe that an
object lives in address-space A so the location expression yields an A-address.

In another email you said: "
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.
".

I assume you mean DW_AT_address_class.  This should do the trick.  I just wasn't
sure if that's the intended use of that attribute.


> > 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.
> 
> Which example?

Table 2.7 "Example address class codes" on p. 48.  It uses DW_AT_address_class
to describe addressing modes.

Regards,
Markus.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Gary Kershaw
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] modeling different address spaces

2020-07-16 Thread David Blaikie via Dwarf-Discuss
On Thu, Jul 16, 2020 at 12:55 PM Michael Eager  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
>
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] modeling different address spaces

2020-07-16 Thread Michael Eager via Dwarf-Discuss

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


Re: [Dwarf-Discuss] modeling different address spaces

2020-07-16 Thread David Blaikie via Dwarf-Discuss
On Thu, Jul 16, 2020 at 11:41 AM Robinson, Paul via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

> (resending, this time without dropping the list from the cc: grump grump)
>
> > -Original Message-
> > From: Dwarf-Discuss  On Behalf
> > Of Michael Eager via Dwarf-Discuss
> > Sent: Thursday, July 16, 2020 2:12 PM
> > To: todd.al...@concurrent-rt.com; Metzger, Markus T
> > 
> > Cc: dwarf-discuss@lists.dwarfstd.org
> > Subject: Re: [Dwarf-Discuss] modeling different address spaces
> >
> > 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.
>
> 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.
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...

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

& 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?


> --paulr
>
> ___
> Dwarf-Discuss mailing list
> Dwarf-Discuss@lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] modeling different address spaces

2020-07-16 Thread Robinson, Paul via Dwarf-Discuss
(resending, this time without dropping the list from the cc: grump grump)

> -Original Message-
> From: Dwarf-Discuss  On Behalf
> Of Michael Eager via Dwarf-Discuss
> Sent: Thursday, July 16, 2020 2:12 PM
> To: todd.al...@concurrent-rt.com; Metzger, Markus T
> 
> Cc: dwarf-discuss@lists.dwarfstd.org
> Subject: Re: [Dwarf-Discuss] modeling different address spaces
> 
> 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.

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.
--paulr

___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] modeling different address spaces

2020-07-16 Thread Robinson, Paul via Dwarf-Discuss



> -Original Message-
> From: Dwarf-Discuss  On Behalf
> Of Michael Eager via Dwarf-Discuss
> Sent: Thursday, July 16, 2020 2:22 PM
> To: John DelSignore ; todd.allen@concurrent-
> rt.com; Metzger, Markus T 
> Cc: dwarf-discuss@lists.dwarfstd.org; Tye, Tony 
> Subject: Re: [Dwarf-Discuss] modeling different address spaces
> 
> On 7/16/20 10:26 AM, John DelSignore via Dwarf-Discuss wrote:
> > 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://urldefense.com/v3/__https://llvm.org/docs/AMDGPUDwarfProposalForHe
> terogeneousDebugging.html__;!!JmoZiZGBv3RvKRSx!rcLFM5tXmxFw3UnRNhyWapnfPy9
> w2jREY_Id2g3BwR_gCVTPgXEAsLA2NKIn2q-qcA$
> >
> > AFAIK, these changes will be made to LLVM and there is interest in
> adding to the DWARF standard eventually.
> 
> As mentioned in the past, I would be pleased to see proposals submitted
> for these changes.
> 
> I would like to avoid the situation where we have an informal proposal
> lacking specific changes to the DWARF standard, matched with an
> implementation which claims to match the proposal.  That's the opposite
> of standardization.

I think the idea was, it would be implementation experience, which will
inform the proposal.  I've had "review this work" on my to-do list for
an embarrassingly long time now.  The initial problem is that it's a
huge chunk of stuff and is a big time investment to look at.
--paulr

> 
> --
> Michael Eager
> ___
> Dwarf-Discuss mailing list
> Dwarf-Discuss@lists.dwarfstd.org
> https://urldefense.com/v3/__http://lists.dwarfstd.org/listinfo.cgi/dwarf-
> discuss-
> dwarfstd.org__;!!JmoZiZGBv3RvKRSx!rcLFM5tXmxFw3UnRNhyWapnfPy9w2jREY_Id2g3B
> wR_gCVTPgXEAsLA2NKK8z2h0fg$
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] modeling different address spaces

2020-07-16 Thread Michael Eager via Dwarf-Discuss

On 7/16/20 10:26 AM, John DelSignore via Dwarf-Discuss wrote:

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.


As mentioned in the past, I would be pleased to see proposals submitted 
for these changes.


I would like to avoid the situation where we have an informal proposal 
lacking specific changes to the DWARF standard, matched with an 
implementation which claims to match the proposal.  That's the opposite 
of standardization.


--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


Re: [Dwarf-Discuss] modeling different address spaces

2020-07-16 Thread Michael Eager via Dwarf-Discuss

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 +, 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


Re: [Dwarf-Discuss] modeling different address spaces

2020-07-16 Thread John DelSignore via Dwarf-Discuss
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 +, 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


Re: [Dwarf-Discuss] modeling different address spaces

2020-07-16 Thread Todd Allen via Dwarf-Discuss
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 +, 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


Re: [Dwarf-Discuss] modeling different address spaces

2020-07-16 Thread Michael Eager via Dwarf-Discuss

On 7/16/20 2:23 AM, Metzger, Markus T via Dwarf-Discuss wrote:

Hello,

What would be the recommended way to model variables that are allocated 
to different address spaces?


Can you describe the architecture a bit?

I found DW_OPT_xderef for dereferencing address-space qualified pointers 
but the resulting memory location description wouldn’t have an 
address-space qualifier.


DW_OPT_xderef translates from an architecturally defined memory 
reference including an address space into a linear address space 
(generic type).  DWARF doesn't support computations on address-space 
qualified addresses, although using a typed stack, this could be an 
extension.


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.


Which example?

--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


[Dwarf-Discuss] modeling different address spaces

2020-07-16 Thread Metzger, Markus T via Dwarf-Discuss
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.

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Gary Kershaw
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org