[Bug sanitizer/88684] Please make SANITIZER_NON_UNIQUE_TYPEINFO a runtime flag (or always true)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88684 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Martin Liška --- Fixed on trunk, not planning to backport that.
[Bug sanitizer/88684] Please make SANITIZER_NON_UNIQUE_TYPEINFO a runtime flag (or always true)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88684 --- Comment #13 from Martin Liška --- Author: marxin Date: Wed Mar 6 11:46:15 2019 New Revision: 269419 URL: https://gcc.gnu.org/viewcvs?rev=269419=gcc=rev Log: Charry pick libsanitizer r355488 (PR sanitizer/88684). 2019-03-06 Martin Liska PR sanitizer/88684 * sanitizer_common/sanitizer_platform.h (defined): Cherry pick. (SANITIZER_NON_UNIQUE_TYPEINFO): Likewise. * ubsan/ubsan_type_hash_itanium.cc (isDerivedFromAtOffset): Likewise. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/sanitizer_common/sanitizer_platform.h trunk/libsanitizer/ubsan/ubsan_type_hash_itanium.cc
[Bug sanitizer/88684] Please make SANITIZER_NON_UNIQUE_TYPEINFO a runtime flag (or always true)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88684 --- Comment #12 from Martin Liška --- (In reply to Rafael Avila de Espindola from comment #11) > (In reply to Martin Liška from comment #10) > > > That said, I'm willing to ack it for GCC9 even then if upstream comes up > > > with something or if they don't care, eventually as a GCC only tweak. > > > > Works for me. Note that so far there has been no reply to my patch. > > You might want to CC: > Filipe Cabecinhas I've just done that, thanks.
[Bug sanitizer/88684] Please make SANITIZER_NON_UNIQUE_TYPEINFO a runtime flag (or always true)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88684 --- Comment #11 from Rafael Avila de Espindola --- (In reply to Martin Liška from comment #10) > > That said, I'm willing to ack it for GCC9 even then if upstream comes up > > with something or if they don't care, eventually as a GCC only tweak. > > Works for me. Note that so far there has been no reply to my patch. You might want to CC: Filipe Cabecinhas
[Bug sanitizer/88684] Please make SANITIZER_NON_UNIQUE_TYPEINFO a runtime flag (or always true)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88684 Martin Liška changed: What|Removed |Added Target Milestone|--- |9.0 --- Comment #10 from Martin Liška --- > That said, I'm willing to ack it for GCC9 even then if upstream comes up > with something or if they don't care, eventually as a GCC only tweak. Works for me. Note that so far there has been no reply to my patch.
[Bug sanitizer/88684] Please make SANITIZER_NON_UNIQUE_TYPEINFO a runtime flag (or always true)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88684 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |--- Summary|[7/8/9 Regression] Please |Please make |make|SANITIZER_NON_UNIQUE_TYPEIN |SANITIZER_NON_UNIQUE_TYPEIN |FO a runtime flag (or |FO a runtime flag (or |always true) |always true)| --- Comment #9 from Jakub Jelinek --- Why is this actually considered a regression? While in GCC 6 and older libsanitizer didn't have SANITIZER_NON_UNIQUE_TYPEINFO macro, it performed only == comparisons of the string pointers, so in the end it acted as if the current default of SANITIZER_NON_UNIQUE_TYPEINFO. Not suitable for libstdc++, sure, but not a regression. That said, I'm willing to ack it for GCC9 even then if upstream comes up with something or if they don't care, eventually as a GCC only tweak.
[Bug sanitizer/88684] Please make SANITIZER_NON_UNIQUE_TYPEINFO a runtime flag (or always true)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88684 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-07 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- I can confirm that: $ g++ lib.cc -shared -fPIC -o libx.so -fsanitize=undefined && g++ test.cc -lx -L. -fvisibility=hidden -fsanitize=undefined && ./a.out 3bar (0x77ff2007), 3bar (0x77ff2007) 3bar (0x77ff2007), 3foo (0x402048) 3foo (0x77ff200c), 3foo (0x402048) lib.hh:4:8: runtime error: member call on address 0x7fffdc38 which does not point to an object of type 'foo' 0x7fffdc38: note: object is of type 'bar' ff 7f 00 00 50 3d 40 00 00 00 00 00 70 14 40 00 00 00 00 00 eb 6f cf f6 ff 7f 00 00 68 ff ff ff ^~~ vptr for 'bar' with the suggested patch: $ g++ lib.cc -shared -fPIC -o libx.so -fsanitize=undefined && g++ test.cc -lx -L. -fsanitize=undefined && ./a.out 3bar (0x77ff2007), 3bar (0x77ff2007) 3bar (0x77ff2007), 3foo (0x402048) 3foo (0x402048), 3foo (0x402048) Jakub do you prefer to come up with a run-time option or hard-code SANITIZER_NON_UNIQUE_TYPEINFO == 1? Btw. llvm looks to survive the test, the difference I see in nm is: GCC: $ nm -C a.out | grep 'typeinfo name' 00402048 V typeinfo name for foo $ nm -C libx.so | grep 'typeinfo name' 2007 V typeinfo name for bar 200c V typeinfo name for foo clang7: $ nm -C a.out | grep 'typeinfo name' 0042ca70 V typeinfo name for foo 0042c9f7 V typeinfo name for int (int, char**) $ nm -C libx.so | grep 'typeinfo name' 201c R typeinfo name for bar 2034 V typeinfo name for foo
