on trunk 20161110, libubsan is missing some symbols while not changing the soname: libubsan: +#MISSING: 7-20161110-1# __ubsan_handle_cfi_bad_icall@Base 6 +#MISSING: 7-20161110-1# __ubsan_handle_cfi_bad_icall_abort@Base 6 +#MISSING: 7-20161110-1# __ubsan_handle_cfi_bad_type@Base 6 +#MISSING: 7-20161110-1# __ubsan_handle_cfi_bad_type_abort@Base 6
Did this cause the link error? AFAIK GCC doesn't support CFI thus doesn't emit these symbols at compiler side.
I can't tell. I was just looking at symbol difference in the library, like using the abigail tools.
Sure, it doesn't affect gcc emitted code unless somebody calls those directly, but perhaps say llvm compiled code using the shared libubsan.so. In any case, we shouldn't be making ABI incompatible changes in the libraries. So, either we should bump soname, or preferably, if it is not that hard to readd those symbols, just do that, so that people don't have to fight yet another changed library.
(In reply to Jakub Jelinek from comment #3) > Sure, it doesn't affect gcc emitted code unless somebody calls those > directly, but perhaps say llvm compiled code using the shared libubsan.so. But LLVM doesn't support shared UBSan runtime (the only one supported is ASan) and AFAIK there aren't any plans to support it there. > In any case, we shouldn't be making ABI incompatible changes in the > libraries. So, either we should bump soname, or preferably, if it is not > that hard to readd those symbols, just do that, so that people don't have to > fight yet another changed library. Do you mean we can apply a local patch?
(In reply to Maxim Ostapenko from comment #4) > But LLVM doesn't support shared UBSan runtime (the only one supported is > ASan) and AFAIK there aren't any plans to support it there. Yeah, it is a very weird policy. > > In any case, we shouldn't be making ABI incompatible changes in the > > libraries. So, either we should bump soname, or preferably, if it is not > > that hard to readd those symbols, just do that, so that people don't have to > > fight yet another changed library. > > Do you mean we can apply a local patch? We can, sure.
(In reply to Jakub Jelinek from comment #5) > (In reply to Maxim Ostapenko from comment #4) > > But LLVM doesn't support shared UBSan runtime (the only one supported is > > ASan) and AFAIK there aren't any plans to support it there. > > Yeah, it is a very weird policy. > > > > In any case, we shouldn't be making ABI incompatible changes in the > > > libraries. So, either we should bump soname, or preferably, if it is not > > > that hard to readd those symbols, just do that, so that people don't have to > > > fight yet another changed library. > > > > Do you mean we can apply a local patch? > > We can, sure. Ok, I think I can just add (perhaps empty?) stubs into libubsan to readd those symbols, this should be quite trivial.
(In reply to Maxim Ostapenko from comment #6) > (In reply to Jakub Jelinek from comment #5) > > (In reply to Maxim Ostapenko from comment #4) > > > But LLVM doesn't support shared UBSan runtime (the only one supported is > > > ASan) and AFAIK there aren't any plans to support it there. > > > > Yeah, it is a very weird policy. > > > > > > In any case, we shouldn't be making ABI incompatible changes in the > > > > libraries. So, either we should bump soname, or preferably, if it is not > > > > that hard to readd those symbols, just do that, so that people don't have to > > > > fight yet another changed library. > > > > > > Do you mean we can apply a local patch? > > > > We can, sure. > > Ok, I think I can just add (perhaps empty?) stubs into libubsan to readd > those symbols, this should be quite trivial. I think we shouldn't add empty functions, instead look at upstream http://llvm.org/viewvc/llvm-project?view=revision&revision=258744 change and undo the - parts of it essentially - most likely translate the old CFIBadTypeData structure we are given into the new CFICheckFailData and just call HandleCFIBadType.
Author: chefmax Date: Wed Nov 16 11:13:19 2016 New Revision: 242478 URL: https://gcc.gnu.org/viewcvs?rev=242478&root=gcc&view=rev Log: PR sanitizer/78307 * ubsan/ubsan_handlers.cc (__ubsan_handle_cfi_bad_icall): New function. ( __ubsan_handle_cfi_bad_icall_abort): Likewise. * ubsan/ubsan_handlers.h (struct CFIBadIcallData): New type. * ubsan/ubsan_handlers_cxx.cc (__ubsan_handle_cfi_bad_type): New function. (__ubsan_handle_cfi_bad_type_abort): Likewise. * ubsan/ubsan_handlers_cxx.h (struct CFIBadTypeData): New type. (__ubsan_handle_cfi_bad_type): Export function. (__ubsan_handle_cfi_bad_type_abort): Likewise. * HOWTO_MERGE: Update documentation. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/HOWTO_MERGE trunk/libsanitizer/ubsan/ubsan_handlers.cc trunk/libsanitizer/ubsan/ubsan_handlers.h trunk/libsanitizer/ubsan/ubsan_handlers_cxx.cc trunk/libsanitizer/ubsan/ubsan_handlers_cxx.h
Can we close this?
I think so.