http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #33 from Kostya Serebryany <kcc at gcc dot gnu.org> 2013-02-12 07:02:40 UTC --- (In reply to comment #31) > If the mapping is so flexible, how can you detect mismatches? Different scale > or shadow offsets are ABI incompatible... We don't detect mismatches. This has never been a problem for our users (who build everything from scratch) but we do see it as a coming problem as asan is becoming more popular. (in reply to comment from another bug) > Perhaps instead of global vars defined outside of libasan (which e.g. requires > GOT accesses to those vars in libasan) Accessing these vars was never a perf problem (we run asan with perf regularly) > , it might be better to have the scale > and offset as arguments of __asan_init? We did this in the very early version, but it did not work in general. Consider you are linking your program with a third-party object not built with asan. It may have constructor functions called before main and before __asan_init, and those functions call malloc which has to call __asan_init, but can not pass arguments. In some cases we can use .preinit_array to call __asan_init there, but that is not always available (?). We were (and still are) thinking about encoding the abi version in the name of the init function, e.g. __asan_init_v_123. It will help us detect abi mismatches when two objects are instrumented with different generations of asan. This doesn't solve the problem of using different offsets though. > Then you could easily test at runtime, > whether all compilation units agree on the same offset/scale, and complain if > they don't. Then __asan_mapping_offset and __asan_mapping_scale or how are > the > vars called could be hidden attribute, used with PC relative addressing and > avoid one extra indirection, and more importantly have better runtime checking > of mismatches.
