[PATCH] D11635: DebugInfo: Emit DW_AT_address_class for non-0 address space

[Matt Arsenault]

On 08/03/2015 11:27 AM, David Blaikie wrote:
>
>
> On Mon, Aug 3, 2015 at 11:25 AM, Matt Arsenault 
> <Matthew.Arsenault at amd.com <mailto:Matthew.Arsenault at amd.com>> wrote:
>
>     On 07/31/2015 10:12 AM, David Blaikie wrote:
>>
>>
>>     On Fri, Jul 31, 2015 at 9:59 AM, Matt Arsenault
>>     <Matthew.Arsenault at amd.com <mailto:Matthew.Arsenault at amd.com>> wrote:
>>
>>         On 07/31/2015 06:46 AM, Robinson, Paul wrote:
>>>
>>>         The debug info generally should be mapping the source to the
>>>         code/data as actually generated, even after optimizations
>>>         shuffle things around. If the original code thinks it's
>>>         allocating something in AS 0 but optimization puts it in AS
>>>         3, and the user asks the debugger to display the value, how
>>>         does the debugger know to look in AS 3?  Asking the debugger
>>>         to troll around looking for an instruction that it might
>>>         guess is loading/storing the value and assuming that address
>>>         is the actual location… seems like asking a bit much.
>>>
>>>         --paulr
>>>
>>         It seems like a single attribute for the debug address space
>>         isn't enough then to describe both.
>>
>>
>>     Why do you need to describe the original address space, rather
>>     than only the one where the value actually resides? What would
>>     the debugger use this information for? Does this need to be
>>     rendered to the user? For what reason?
>     Yes, it should be shown to the user. It's part of the variable the
>     source declared, just like the type name. In OpenCL it has a lot
>     of consequences for how that variable behaves w.r.t.
>     synchronization issues and other things. Although this leads me to
>     another question for the clang component emitting it, whether the
>     source address space ID as defined by clang should be emitted for
>     this attribute, or the target mapped address space ID. Since these
>     all end up as 0 on x86 for example, it probably should be the
>     clang source ID in that case.
>
>>
>>     (hmm, speaking of which - perhaps this shouldn't be an attribute
>>     on the variable, but instead part of the DWARF expression
>>     describing the location of the value? If it's possible that
>>     optimizations would put the value in one location with one
>>     address space at point A, and a different location in a different
>>     address space at point B)
>>
>     I don't know much about DWARF. I don't think there's any reason
>     why a value would be duplicated into two different address spaces.
>
>     I just checked the spec again and the description of
>     DW_AT_address_class seems vague on what it is meant for. It says
>     "DW_AT_address_class attribute to describe how objects having the
>     given pointer or reference type ought to be dereferenced." which
>     seems to not be describing what the source looks like.
>
>
> DWARF is somewhat intentionally vague.
>
> Let's start here: Why are you implementing this? Do you have users 
> filing bugs about sub-optimal debugging behavior? Have you observed 
> same? Does this patch help/address that behavior?
>
I'm upstreaming some of our internal debug info support patches for 
AMDIL/HSAIL. This is the most important one, which currently reports the 
backend address space ID which in this case happens to have a 1:1 
mapping with the source language. Not having the address space at all in 
the debug info is a show stopper for the OpenCL debugger. The question 
of optimizations changing the address space is a bit of an academic 
question at this point since HSAIL does not have any optimizations at 
this time that do this.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150803/5182d611/attachment.html>