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

[David Blaikie]

On Mon, Aug 3, 2015 at 11:25 AM, Matt Arsenault <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
> > 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150803/d3c8161d/attachment.html>