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

[David Blaikie]

On Mon, Aug 3, 2015 at 11:33 AM, Matt Arsenault <Matthew.Arsenault at amd.com>
wrote:

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

Somewhat, yes - but it's vaguely important to implementing this the right
way in LLVM.

Why is this a showstopper to the OpenCL debugger? I would imagine if it's
purely just for printing things to the user that it's not exactly critical
(it doesn't make a program undebuggable). So I assume the debugger is
actually using the address space to make choices about how to access
things/print them/etc - in which case it seems appropriate to encode the
address space of the actual variable (if it's been optimized, moved, etc -
as the (hypothetical/future) examples you gave). & I'd imagine, if a
variable can be optimized into a different address space in some
circumstances, it seems plausible that it could be in different address
spaces at different times, potentially - so looking at the address space of
the actual variable value being described (& perhaps there's a DWARF
encoding for address space in the DWARF location expression syntax, so it
can be described on a per-location basis) would be the right choice.

But of course I know epsilon about any of this.

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