https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78307
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (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.
