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

David Blaikie dblaikie at gmail.com
Thu Jul 30 10:39:50 PDT 2015


On Thu, Jul 30, 2015 at 10:27 AM, Matt Arsenault <arsenm2 at gmail.com> wrote:

>
> On Jul 30, 2015, at 4:55 AM, David Blaikie <dblaikie at gmail.com> wrote:
>
> Hey Duncan - what's this "extraData" field intended for? Is this a
> reasonable use of it?
>
> I imagine we just want to extend the schema here to explicitly include
> address space?
>
>
> One thing I was worried about was whether we would want the address space
> for some of the other DW_TAG types that use extraData. Eventually we may
> want to be able to apply the address space to static members and the others
> (also I forgot to update the comment on getExtraData to include this new
> use) so a separate field is probably a good idea
>

Yeah, in theory we'd just add a new field to those things too.


>
>
> Could we instead extract it from the value we're describing? (probably
> not? if the address happens to be a constant or something (which I guess is
> more likely in custom address spaces) it wouldn't be carrying explicit
> address space info?)
>
>
> This won’t work. The most common case for us are non-zero address space
> function arguments.
>

Why would that be a problem for this idea? The function argument would have
a pointer type with an associated non-zero address space & the debug info
would point to that & we could consult the pointer type to see the address
space, no?

But I'm OK with not doing it that way (happy to better understand why) &
just make it a new field in the schema, etc, as above.


> Ideally we wouldn’t ever use LLVM address space 0 for anything, although
> we can’t do that today. One problem I noticed here is this doesn’t seem to
> get applied in the case where a global is put in a different address space,
> when the address is sometimes constant.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150730/0eae96d0/attachment.html>


More information about the llvm-commits mailing list