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

[David Blaikie]

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?

(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'm fine with just keeping it as the constant source, and saying that this
> is one of those optimizations that destroys hope of sensible debugging. We
> also have some possible use cases for non-optimization purposes where an
> address space ID would be changed in the backend, but would be an alias for
> the original address space. The object isn't literally moved to a different
> address space, and is for the backend's benefit so ideally the user
> debugging would never be aware that this occurred.
>
> -Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150731/a27511b5/attachment.html>