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

[Matt Arsenault]

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.

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