Re: [PATCH] Emit DWARF5 DW_AT_export_symbols for namespaces

[Jakub Jelinek <jakub at redhat dot com>]

On Tue, Jul 25, 2017 at 01:45:31PM +0200, Marek Polacek wrote:
> > This patch doesn't do anything about anon struct/union/class, I've tried
> > to handle it, the problem is that ANON_AGGR_TYPE_P flag is set too late,
> > after the debug hook adds the type DIE.  Any thoughts on how to handle that?
> > And I wonder what is the counterpart of ANON_AGGR_TYPE_P in the C FE, CCing
> > Marek on that.
> 
> I think you need to check RECORD_OR_UNION_TYPE_P && DECL_NAME == NULL_TREE.
> Or do it in grokfield -- would that work?

One thing is that the information needs to be propagated from the FE to
dwarf2out somehow.

And the second thing is that it isn't really clear to me when exactly do we
want to use DW_AT_export_symbols on types with no name.

Consider:

struct { int a, b; } c;
typedef struct { int d, e; } f;
struct S {
  f h;
#ifdef MS_EXTENSIONS
  f;
#endif
  struct { int i, j; };
  struct { int k, l; } m;
} g;

with -g -dA {,-DMS_EXTENSIONS -fms-extensions}
(or -fplan9-extensions).
For the struct with i/j fields we clearly want the DW_AT_export_symbols
on it, for the struct with k/l fields I think we don't, the fields of that
structure aren't exported into the outer namespace.
And then there is the case of the misdesigned Plan9 and Microsoft
extensions, the same type then can be used once as not really exporting
stuff out of it and another time as doing that.

Guess my preference would be to only mark i+j struct here, i.e. struct/union
with DECL_NAME NULL with DECL_CONTEXT of some aggregate where there are no
named fields with that type in the aggregate.
It might be a good idea to change DWARF6 so that DW_AT_export_symbols is
also allowed on DW_TAG_member and emit it that way for the f; case above.

Another issue is that DWARF5 D.2.5 lists the anonymous structure nested
as child of the outer structure, so just for:
struct T { struct { int n; }; };
DW_TAG_structure_type
  DW_AT_name T
  DW_TAG_structure_type
    DW_AT_export_symbols
    DW_TAG_member
      DW_AT_name n
but what GCC emits is:
1: DW_TAG_structure_type
  DW_TAG_member
    DW_AT_name n
DW_TAG_structure_type
  DW_AT_name T
    DW_TAG_member
      DW_AT_type 1b

Maybe at least for -gdwarf-5 we should start moving stuff into the right
context.

	Jakub