On Wed, Feb 20, 2013 at 08:23:34PM -0800, John McCall wrote: > On Feb 20, 2013, at 8:08 PM, Richard Smith <[email protected]> wrote: > > On Wed, Feb 20, 2013 at 7:52 PM, John McCall <[email protected]> wrote: > > On Feb 20, 2013, at 7:49 PM, Peter Collingbourne <[email protected]> wrote: > > > On Wed, Feb 20, 2013 at 06:30:53PM -0800, John McCall wrote: > > >> On Feb 20, 2013, at 6:24 PM, Richard Smith <[email protected]> wrote: > > >>> On Wed, Feb 20, 2013 at 6:18 PM, John McCall <[email protected]> wrote: > > >>> On Feb 20, 2013, at 6:13 PM, Peter Collingbourne <[email protected]> > > >>> wrote: > > >>>> http://llvm-reviews.chandlerc.com/D443 > > >>> > > >>> Are you sure we actually *want* to expose this to users? > > >>> > > >>> I would like to mark the UBSan runtime handler functions as > > >>> __attribute__((coldcc)), and I think that would make sense for other > > >>> sanitizers too. > > >> > > >> Are we now willing to commit to a fixed ABI for coldcc? I thought we > > >> hadn't been. > > > > > > Implementing __attribute__((coldcc)) does not necessarily imply fixing > > > the ABI, provided that we document the attribute as such. It should > > > be safe to use in compiler_rt once we modify its build system to use the > > > just-built clang. > > > > I agree that we could certainly expose a calling convention with zero > > binary-compatibility guarantees. I don't know if that would work for what > > Richard wants, though. Notably, you can't stick that sort of thing in a > > library that you haven't rev-locked to the compiler. > > > > The ubsan runtime is essentially rev-locked to the compiler right now, and > > certainly does not guarantee a stable ABI. But Chandler has suggested a > > seemingly better solution anyway: emit noinline linkonce_odr coldcc > > forwarding thunks for all ubsan runtime functions called in a TU, and call > > them instead. > > Plus hidden visibility, but yes, this seems like a good idea.
This seems like it would work fine as a short term solution. The runtimes aren't entirely rev-locked to the compiler due to the aforementioned build system issue but that is probably something we can look at in the long term. Thanks, -- Peter _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
