[PATCH] D19668: [ubsan] Minimize size of data for type_mismatch

Kostya Serebryany via llvm-commits llvm-commits at lists.llvm.org
Thu May 26 11:28:27 PDT 2016


kcc added a comment.

In http://reviews.llvm.org/D19668#441261, @filcab wrote:

> In http://reviews.llvm.org/D19668#441079, @kcc wrote:
>
> > Sorry, I missed this CL. 
> >  Could you please repeat why we need backwards compatibility?
> >
> > I would rather prefer to not have this complexity, but instead make sure we don't mix old API and the new one, 
> >  e.g. the same way we do it in asan. (see asan/asan_init_version.h)
>
>
> The backwards compatibility was to be able to mix older files, like when we upgraded the float cast overflow to be able to deal with having the source location or not.
>
> From your comment it seems you'd prefer one of:
>
> - Just use the newer and users have to match versions of clang with the ubsan runtime (I think this is acceptable, but I might be an edge case ;-) )
> - Create `__ubsan_handle_type_mismatch2` and `__ubsan_handle_type_mismatch2_abort` (or similar) and use the new struct with that (no need to add a Version field if we do it this way, but we'll have functions that might just start to bitrot)
>
>   I think doing ABI versions the way ASan does them doesn't really work that well for UBSan, since the checks are mostly spot checks, which don't depend on each other. I think the best it to either don't version it and say users are responsible for matching revs, or have versions per check.


I don't want to have multiple versions in the code base as it makes code maintenance more expensive. 
Making "users are responsible for X" work only if the users know when the break X.
Will they know it in this case, or things will break silently?

> Which one would you prefer (I have mild preference for one, but no strong opinion)?



http://reviews.llvm.org/D19668





More information about the llvm-commits mailing list