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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
