-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Read corpus from elf path #2
Comments
woodard
pushed a commit
that referenced
this issue
Mar 22, 2022
This commit re-visit the commit below: commit 1cfbff1 Author: Dodji Seketeli <[email protected]> Date: Mon Jun 7 16:07:50 2021 +0200 rhbz1951526 - SELF CHECK FAILED for 'gimp-2.10' This is a fix for bug https://bugzilla.redhat.com/show_bug.cgi?id=1951526. Basically, this commits makes is so that two enums below are considered equal by libabigail: enum foo // This is foo #1 { e0 = 0; e1 = 1; e2 = 2; }; enum foo // This is foo #2 { e0 = 0; e1 = 1; e2 = 2; e_added = 1; // This enumerator is considered redundant // with the enumerator e1 because their values // are the same. }; With this patch, foo #1 and foo #2 are considered equal, just like in the original commit 1cfbff1. In the original commit however, this was achieved by comparing the enums without considering their enumerator names. This was named "binary-only enum comparison". In reality, that approach was too big of a hammer and was causing the issues raised in the bug. Namely, type canonicalization would conflate anonymous enums that were unrelated (precisely because their enumerator names were different), leading to spurious type change reports when comparing abixml files pre-dating commit 1cfbff1 with posterior abixml files. If I refer to the example above with foo #1 and #2, this patch detects that the value of the enumerator 'e_added' is redundant with the value of the enumerator e1. As such, the two foo #1 and #2 are considered equal. Enumerator names are now fully taken into account. With this precise approach, it now seems we can do away with the careful dance of using "binary-only enum comparison" at some precise times of the libabigail pipeline. Now, we can just use the new enum comparison scheme all the time. Leading to less (complicated) code and a hopefully accurate representation. * include/abg-ir.h (environment::use_enum_binary_only_equality): Remove. * src/abg-comparison.cc (compute_diff): In the overload for enum_type_decl, stop using binary-only-equality for enums. * src/abg-dwarf-reader.cc (read_context::compare_before_canonicalisation): Likewise. * src/abg-ir.cc (environment::use_enum_binary_only_equality): Remove. (enumerators_values_are_equal) (is_enumerator_value_present_in_enum) (is_enumerator_value_redundant): Define new static functions. (equals): In the overload for enum_type_decl, use the new is_enumerator_value_redundant to detect if two enums are equal modulo a redundant enumerator value. In that case, consider they are equal. * tests/data/test-abidiff/test-enum0-report.txt: Adjust. * tests/data/test-annotate/test-anonymous-members-0.o.abi: Likewise. * tests/data/test-annotate/test18-pr19037-libvtkRenderingLIC-6.1.so.abi: Likewise. * tests/data/test-annotate/test19-pr19023-libtcmalloc_and_profiler.so.abi: Likewise. * tests/data/test-diff-dwarf/PR25058-liblttng-ctl-report-1.txt: Likewise. * tests/data/test-read-dwarf/test18-pr19037-libvtkRenderingLIC-6.1.so.abi: Likewise. * tests/data/test-read-dwarf/test19-pr19023-libtcmalloc_and_profiler.so.abi: Likewise. * tests/data/test-read-dwarf/test22-pr19097-libstdc++.so.6.0.17.so.abi: Likewise. Signed-off-by: Dodji Seketeli <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I stumbled on a function that I think we can better use to read an application and get a corpus, here: https://github.com/woodard/libabigail/blob/master/src/abg-dwarf-reader.cc#L17424. Specifically, this is how it's done in
abicompat
, differently fromabidw
where the context is created in the function directly. I want to open an issue here as a note to myself to try updating to this simpler form after we get #1 figured out.The text was updated successfully, but these errors were encountered: