public inbox for libabigail@sourceware.org
 help / color / mirror / Atom feed
From: Dodji Seketeli <dodji@redhat.com>
To: libabigail@sourceware.org
Cc: gprocida@google.com, maennich@google.com
Subject: [PATCH 2/2] Bug 26646 - unexpected declaration-only types
Date: Mon, 07 Feb 2022 12:11:23 +0100	[thread overview]
Message-ID: <87mtj3lyn8.fsf@seketeli.org> (raw)
In-Reply-To: <87v8xrlyyd.fsf@redhat.com> (Dodji Seketeli via Libabigail's message of "Mon, 07 Feb 2022 12:04:42 +0100")


In a version of the kernel binary referred to in this problem report,
the parameter 'skb' of the udp4_hwcsum function, which is of type
"pointer to struct sk_buff", indirectly refers to a pointer to a
declaration-only struct ip_mc_list.

In another version of that kernel binary, the same parameter skb of
the udp4_hwcsum function is still of type "pointer to struct sk_buff",
but in that case, the sk_buff indirectly refers to a pointer to a
fully defined struct ip_mc_list.

The first kernel only contains a decl-only struct ip_mc_list whereas
the second one contains a fully defined struct ip_mc_list.

This problem comes from the fact that in add_or_update_class_type, we
"reuse" the "struct sk_buff" that we've already seen in the same
binary, if any.  Depending on the order in which types are defined in
the debug information, if the DIE for struct sk_buff that refers to a
decl-only struct ip_mc_list has already been "seen" by the
DWARF-reader, then add_or_update_class_type re-uses the IR of that DIE
that's been constructed already; otherwise, the IR for the struct
sk_buff represented by the current DIE is constructed.

This patch fixes the problem by always constructing an IR for the
DIE that is being seen, in add_or_update_class_type.

	* src/abg-dwarf-reader.cc (add_or_update_class_type): Do not reuse
	the IR for a DIE with the same textual representation as the one
	we are seeing now.
	* tests/data/test-annotate/test21-pr19092.so.abi: Adjust.
	* tests/data/test-read-dwarf/test21-pr19092.so.abi: Likewise.

Signed-off-by: Dodji Seketeli <dodji@redhat.com>
---
 src/abg-dwarf-reader.cc                          | 13 -------------
 tests/data/test-annotate/test21-pr19092.so.abi   |  2 +-
 tests/data/test-read-dwarf/test21-pr19092.so.abi |  2 +-
 3 files changed, 2 insertions(+), 15 deletions(-)

diff --git a/src/abg-dwarf-reader.cc b/src/abg-dwarf-reader.cc
index d8545b4c..53b5845d 100644
--- a/src/abg-dwarf-reader.cc
+++ b/src/abg-dwarf-reader.cc
@@ -12160,19 +12160,6 @@ add_or_update_class_type(read_context&	 ctxt,
       }
   }
 
-  if (!ctxt.die_is_in_cplus_plus(die))
-    // In c++, a given class might be put together "piecewise".  That
-    // is, in a translation unit, some data members of that class
-    // might be defined; then in another later, some member types
-    // might be defined.  So we can't just re-use a class "verbatim"
-    // just because we've seen previously.  So in c++, re-using the
-    // class is a much clever process.  In the other languages however
-    // (like in C) we can re-use a class definition verbatim.
-    if (class_decl_sptr class_type =
-	is_class_type(ctxt.lookup_type_from_die(die)))
-      if (!class_type->get_is_declaration_only())
-	return class_type;
-
   string name, linkage_name;
   location loc;
   die_loc_and_name(ctxt, die, loc, name, linkage_name);
diff --git a/tests/data/test-annotate/test21-pr19092.so.abi b/tests/data/test-annotate/test21-pr19092.so.abi
index e009a191..bb87fc54 100644
--- a/tests/data/test-annotate/test21-pr19092.so.abi
+++ b/tests/data/test-annotate/test21-pr19092.so.abi
@@ -4395,7 +4395,7 @@
       </data-member>
     </class-decl>
     <!-- struct htab -->
-    <class-decl name='htab' size-in-bits='896' is-struct='yes' visibility='default' filepath='../.././libcpp/../include/hashtab.h' line='100' column='1' id='type-id-208'>
+    <class-decl name='htab' size-in-bits='896' is-struct='yes' visibility='default' filepath='../.././libiberty/../include/hashtab.h' line='100' column='1' id='type-id-208'>
       <data-member access='public' layout-offset-in-bits='0'>
         <!-- htab_hash htab::hash_f -->
         <var-decl name='hash_f' type-id='type-id-183' visibility='default' filepath='../.././gcc/../include/hashtab.h' line='102' column='1'/>
diff --git a/tests/data/test-read-dwarf/test21-pr19092.so.abi b/tests/data/test-read-dwarf/test21-pr19092.so.abi
index c10916fa..90ecd590 100644
--- a/tests/data/test-read-dwarf/test21-pr19092.so.abi
+++ b/tests/data/test-read-dwarf/test21-pr19092.so.abi
@@ -2915,7 +2915,7 @@
         <var-decl name='next' type-id='type-id-207' visibility='default' filepath='../.././gcc/tlink.c' line='199' column='1'/>
       </data-member>
     </class-decl>
-    <class-decl name='htab' size-in-bits='896' is-struct='yes' visibility='default' filepath='../.././libcpp/../include/hashtab.h' line='100' column='1' id='type-id-208'>
+    <class-decl name='htab' size-in-bits='896' is-struct='yes' visibility='default' filepath='../.././libiberty/../include/hashtab.h' line='100' column='1' id='type-id-208'>
       <data-member access='public' layout-offset-in-bits='0'>
         <var-decl name='hash_f' type-id='type-id-183' visibility='default' filepath='../.././gcc/../include/hashtab.h' line='102' column='1'/>
       </data-member>
-- 
2.35.0.rc2



-- 
		Dodji


  parent reply	other threads:[~2022-02-07 11:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-07 11:04 Patch review request for Bug 2664 " Dodji Seketeli
2022-02-07 11:09 ` [PATCH 1/2] symtab-reader: Remove an over-agressive assertion Dodji Seketeli
2022-02-07 15:33   ` Giuliano Procida
2022-02-07 16:49     ` Dodji Seketeli
2022-02-07 11:11 ` Dodji Seketeli [this message]
     [not found]   ` <CAGvU0H=UV0FxvzqhQWRjU6F7_yRMxhEK5P_t3NKMAD02e55rpw@mail.gmail.com>
2022-02-08 10:27     ` [PATCH 2/2] Bug 26646 - unexpected declaration-only types Dodji Seketeli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mtj3lyn8.fsf@seketeli.org \
    --to=dodji@redhat.com \
    --cc=gprocida@google.com \
    --cc=libabigail@sourceware.org \
    --cc=maennich@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).