https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88684
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2019-01-07
Ever confirmed|0 |1
--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
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 (0x7ffff7ff2007), 3bar (0x7ffff7ff2007)
3bar (0x7ffff7ff2007), 3foo (0x402048)
3foo (0x7ffff7ff200c), 3foo (0x402048)
lib.hh:4:8: runtime error: member call on address 0x7fffffffdc38 which does not
point to an object of type 'foo'
0x7fffffffdc38: 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 (0x7ffff7ff2007), 3bar (0x7ffff7ff2007)
3bar (0x7ffff7ff2007), 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'
0000000000402048 V typeinfo name for foo
$ nm -C libx.so | grep 'typeinfo name'
0000000000002007 V typeinfo name for bar
000000000000200c V typeinfo name for foo
clang7:
$ nm -C a.out | grep 'typeinfo name'
000000000042ca70 V typeinfo name for foo
000000000042c9f7 V typeinfo name for int (int, char**)
$ nm -C libx.so | grep 'typeinfo name'
000000000000201c R typeinfo name for bar
0000000000002034 V typeinfo name for foo
