DW_AT_data_location: should it have friends?

[todd dot allen at ccur dot com (Todd Allen)]

This new DW_AT_data_location attribute has a lot of potential.  We have these
entities in Ada that we internally call "fat pointers".  They're a pointer to
an extra layer of indirection which is just a struct/record that contains a
pointer to the main entity in question, and also other information.  Is this
the sort of thing that others are using DW_AT_data_location for?

If so, I'm curious about the nature of this other information.  If it just
contains information like array bounds, and that sort of thing, then it's
covered by DWARF already.  But if it's anything more interesting & exotic,
then there's a chance a debugger might care about it.  If so, the DWARF
should describe it.

I have one suggestion already: that new DW_AT_static_link_parameter attribute
I talked about in a previous proposal.  When you use 'Access on a nested
subprogram in Ada, we have to generate a fat pointer containing the address
of the entry point to the subprogram, and the also the static link parameter
to pass to it.

We should allow the DW_AT_static_link_parameter attribute to be associated
with pointer types, too.  So, if a pointer type is capable of referencing a a
nested subroutine, the DW_AT_data_location associated with the pointer type
tells how take the fat pointer address and get the address of the entry
point, and the DW_AT_static_link_parameter tells how to take the fat pointer
address and get the static link to pass to it.  (If the pointer could
potentially designate a nested subroutine, then you have to pass a static
link, even if the actual called subroutine is at the outermost level.  In
that case, the static link is ignored and can be any value.)

Or maybe I'm subtly wrong here.  Maybe both the DW_AT_data_location and
DW_AT_static_link_parameter should be associated with the
DW_TAG_subroutine_type instead of the DW_TAG_pointer_type entry.  What's the
consensus on that?  I guess this isn't ready to be a formal proposal until
that question is answered.

Another case occurs to me, too.  What about the gp pointer that has to be
passed around on the ia64 architecture.  If you have a function pointer on
that architecture, is it really a fat pointer that contains both the entry
point to the subroutine, and also the appropriate gp for that subroutine, in
case it's in a different shared library?  If so, the gp value seems like a
good candidate for another attribute.

-- 
Todd Allen
Concurrent Computer Corporation