On Apr 7, 2017, Alexandre Oliva <aoliva@redhat.com> wrote:
On Mar 21, 2017, Alexandre Oliva <aoliva@redhat.com> wrote:
On Jan 27, 2017, Alexandre Oliva <aoliva@redhat.com> wrote:
On Oct 19, 2016, Alexandre Oliva <aoliva@redhat.com> wrote:
On Sep 23, 2016, Alexandre Oliva <aoliva@redhat.com> wrote:
On Aug 30, 2016, Alexandre Oliva <aoliva@redhat.com> wrote:
Handling non-template friends is kind of easy, [...]
Ping?
Ping? (conflicts resolved, patch refreshed and retested)
Ping? (trivial conflicts resolved)
Ping? https://gcc.gnu.org/ml/gcc-patches/2017-01/msg02112.html
Ping?
Ping? (refreshed, retested)
[PR59319] output friends in debug info
Handling non-template friends is kind of easy, but it required a bit
of infrastructure in dwarf2out to avoid (i) forcing debug info for
unused types or functions: DW_TAG_friend DIEs are only emitted if
their DW_AT_friend DIE is emitted, and (ii) creating DIEs for such
types or functions just to have them discarded at the end. To this
end, I introduced a list (vec, actually) of types with friends,
processed at the end of the translation unit, and a list of
DW_TAG_friend DIEs that, when we're pruning unused types, reference
DIEs that are still not known to be used, revisited after we finish
deciding all other DIEs, so that we prune DIEs that would have
referenced pruned types or functions.
Handling template friends turned out to be trickier: there's no
representation in DWARF for templates. I decided to give debuggers as
much information as possible, enumerating all specializations of
friend templates and outputting DW_TAG_friend DIEs referencing them as
well. I considered marking those as DW_AT_artificial, to indicate
they're not explicitly stated in the source code, but in the end we
decided that was not useful. The greatest challenge was to enumerate
all specializations of a template. It looked trivial at first, given
DECL_TEMPLATE_INSTANTIATIONS, but it won't list specializations of
class-scoped functions and of nested templates. For other templates,
I ended up writing code to look for specializations in the hashtables
of decl or type specializations. That's not exactly efficient, but it
gets the job done.
+ /* At DETAIL level 0, returns non-NULL if the named class TYPE has
+ any friends, NULL otherwise. At higher detail levels, return a
+ tree list with the friends of the named class type. Each
+ TREE_VALUE contains one friend type or function decl. For
+ non-template friends, TREE_PURPOSE is NULL. For template friend
+ declarations, the returned entries depend on the DETAIL level.
+ At level 1, and only at level 1, an entry with NULL TREE_VALUE
+ and non-NULL TREE_PURPOSE will START the returned list to
+ indicate the named class TYPE has at least one template friend.
+ At level 2, each template friend will be in an entry with NULL
+ TREE_VALUE, and with the TEMPLATE_DECL in TREE_PURPOSE. At level
+ 3, instead of a NULL TREE_VALUE, we add one entry for each
+ instantiation or specialization of the template that fits the
+ template friend declaration, as long as there is at least one
+ instantiation or specialization; if there isn't any, an entry
+ with NULL TREE_VALUE is created. A negative detail level will
+ omit non-template friends from the returned list. */