summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorDodji Seketeli <dodji@redhat.com>2022-02-07 11:21:08 +0100
committerDodji Seketeli <dodji@redhat.com>2022-02-08 11:11:51 +0100
commitf86ff3f7a72c0c0d5d48e6f83d4cfcc25e2f57e2 (patch)
treef3082b2f850ddd60457803081872f0c81c6b48de
parentsymtab-reader: Remove an over-agressive assertion (diff)
downloadlibabigail-f86ff3f7a72c0c0d5d48e6f83d4cfcc25e2f57e2.tar.gz
libabigail-f86ff3f7a72c0c0d5d48e6f83d4cfcc25e2f57e2.tar.bz2
libabigail-f86ff3f7a72c0c0d5d48e6f83d4cfcc25e2f57e2.tar.xz
Bug 26646 - unexpected declaration-only types
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>
-rw-r--r--src/abg-dwarf-reader.cc13
-rw-r--r--tests/data/test-annotate/test21-pr19092.so.abi2
-rw-r--r--tests/data/test-read-dwarf/test21-pr19092.so.abi2
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,
12160 } 12160 }
12161 } 12161 }
12162 12162
12163 if (!ctxt.die_is_in_cplus_plus(die))
12164 // In c++, a given class might be put together "piecewise". That
12165 // is, in a translation unit, some data members of that class
12166 // might be defined; then in another later, some member types
12167 // might be defined. So we can't just re-use a class "verbatim"
12168 // just because we've seen previously. So in c++, re-using the
12169 // class is a much clever process. In the other languages however
12170 // (like in C) we can re-use a class definition verbatim.
12171 if (class_decl_sptr class_type =
12172 is_class_type(ctxt.lookup_type_from_die(die)))
12173 if (!class_type->get_is_declaration_only())
12174 return class_type;
12175
12176 string name, linkage_name; 12163 string name, linkage_name;
12177 location loc; 12164 location loc;
12178 die_loc_and_name(ctxt, die, loc, name, linkage_name); 12165 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 @@
4395 </data-member> 4395 </data-member>
4396 </class-decl> 4396 </class-decl>
4397 <!-- struct htab --> 4397 <!-- struct htab -->
4398 <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'> 4398 <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'>
4399 <data-member access='public' layout-offset-in-bits='0'> 4399 <data-member access='public' layout-offset-in-bits='0'>
4400 <!-- htab_hash htab::hash_f --> 4400 <!-- htab_hash htab::hash_f -->
4401 <var-decl name='hash_f' type-id='type-id-183' visibility='default' filepath='../.././gcc/../include/hashtab.h' line='102' column='1'/> 4401 <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 @@
2915 <var-decl name='next' type-id='type-id-207' visibility='default' filepath='../.././gcc/tlink.c' line='199' column='1'/> 2915 <var-decl name='next' type-id='type-id-207' visibility='default' filepath='../.././gcc/tlink.c' line='199' column='1'/>
2916 </data-member> 2916 </data-member>
2917 </class-decl> 2917 </class-decl>
2918 <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'> 2918 <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'>
2919 <data-member access='public' layout-offset-in-bits='0'> 2919 <data-member access='public' layout-offset-in-bits='0'>
2920 <var-decl name='hash_f' type-id='type-id-183' visibility='default' filepath='../.././gcc/../include/hashtab.h' line='102' column='1'/> 2920 <var-decl name='hash_f' type-id='type-id-183' visibility='default' filepath='../.././gcc/../include/hashtab.h' line='102' column='1'/>
2921 </data-member> 2921 </data-member>