From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BA2D13857823; Tue, 6 Apr 2021 20:56:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BA2D13857823 From: "gprocida+abigail at google dot com" To: libabigail@sourceware.org Subject: [Bug default/26591] detect pathologically redundant types in abixml Date: Tue, 06 Apr 2021 20:56:07 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: libabigail X-Bugzilla-Component: default X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: gprocida+abigail at google dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: dodji at redhat dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: libabigail@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list of the Libabigail project List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2021 20:56:07 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D26591 --- Comment #8 from Giuliano Procida -= -- 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: =3D test.h =3D struct N { struct A { struct B { typedef int C; ... }; ... }; ... }; =3D foo.cc =3D N::A::B::C foo; =3D bar.cc =3D N::A::B bar; The variable foo has a type which doesn't depend on the "...", but B depend= s 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 cou= ld 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 addition= ally 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. --=20 You are receiving this mail because: You are on the CC list for the bug.=