From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55151 invoked by alias); 2 Jun 2017 09:56:51 -0000 Mailing-List: contact libabigail-help@sourceware.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Id: List-Subscribe: Sender: libabigail-owner@sourceware.org Received: (qmail 55014 invoked by uid 48); 2 Jun 2017 09:56:47 -0000 From: "dodji at redhat dot com" To: libabigail@sourceware.org Subject: [Bug default/21540] New: Selectively resolve struct/union declaration to their definition Date: Sun, 01 Jan 2017 00:00:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: libabigail X-Bugzilla-Component: default X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dodji at redhat 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone Message-ID: 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-SW-Source: 2017-q2/txt/msg00033.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D21540 Bug ID: 21540 Summary: Selectively resolve struct/union declaration to their definition Product: libabigail Version: unspecified Status: NEW Severity: normal Priority: P2 Component: default Assignee: dodji at redhat dot com Reporter: dodji at redhat dot com CC: libabigail at sourceware dot org Target Milestone: --- When analysing the debug information of a C binary, it can happen that the forward declaration of a "struct foo" can possibly resolve to several *different* definitions of struct foo. Here are the cases we can care abou= t: 1/ a struct foo declaration is followed by a struct foo definition, in the = same compilation unit. 2/ a struct foo is declared in compilation unit CU1, but has no definition = in that cu. There is another compilation unit CU2 that has another struct foo declared. And there is a third CU3 which has a definition of struct foo. = In the entire binary, there is just one *definition* of struct foo. 3/ CU1 and CU2 have declarations of struct foo and no definition. CU3 and = CU4 have two definitions of struct foo that are different. Here are how we need to handle the resolution of the declarations of struct foo. * for 1/ If a definition is found for a declaration in the same CU, then the declara= tion resolves to that definition. * for 2/ If there is just one definition matching a given (or several) declaration, = in the entire binary, then the declaration(s) resolve(s) to that definition. = That is, even if the definition is not in the same CU as the declarations. * for 3/ If a declaration has no definition in the same CU, but if there are more th= an one definition in other CUs that match this declaration, then the declarati= on is left unresolved. It follows that a declaration-only struct foo must compare different to a definition of struct foo, at the comparison engine level. Then at the "diff internal representation" level, we can filter out change reports about a declaration-only becoming a definition. Note that at the moment, a declaration resolves to the last matching defini= tion that was analysed. This makes the declaration resolution be somewhat random= .=20 This needs to be fixed by following what I just outlined above. --=20 You are receiving this mail because: You are on the CC list for the bug.