[Bug default/26591] detect pathologically redundant types in abixml

["gprocida+abigail at google dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=26591

--- Comment #8 from Giuliano Procida <gprocida+abigail at google dot com> ---
I am trying to tackle one source of duplicate type ids: write_decl_in_scope.

The current behaviour likely reflects an implicit design choice, one which I
would like some clarification on. Consider the case of code like this:

= test.h =
struct N {
 struct A {
  struct B {
   typedef int C;
   ...
  };
  ...
 };
 ...
};

= foo.cc =
N::A::B::C foo;

= bar.cc =
N::A::B bar;

The variable foo has a type which doesn't depend on the "...", but B depends on
the first "..." but not the later ones.

If foo were the only symbol, we would could choose to omit the other bits of
the types. (I'm not sure if libabigail does this.)

If bar were the only symbol, we should emit B's definition in full, but could
chose to omit the rest of A. (libabigail actually omits C, but it could be like
that in the DWARF.)

If both foo and bar are processed in that order, it would be good not to
duplicate the definition of C. libabigail currently does duplicate this.
There's no duplication if bar precedes foo.

I see two ways forward:

1. Somehow work out that an enclosing type definition will be emitted anyway
(so just emit that instead, now or later). I can see this being a bit tricky
with multiply-nested types. However, there is probably some existing logic
there already (compare ABIs from g++ -Wall -Wextra -g -shared foo.cc bar.cc -o
test.o and g++ -Wall -Wextra -g -shared bar.cc foo.cc -o test.o).

2. Always emit the outermost enclosing types, now, and not later. This will
make some ABI files larger but should stop there being multiple definitions of
types like C. In the case of the foo, bar example, this would mean additionally
exposing the last "..." in the ABI, even if it's not directly reachable from
the symbols.

I have a tentative patch that does 2. I'll post it for review soon.

-- 
You are receiving this mail because:
You are on the CC list for the bug.