[PATCH] Add support for coldcc to clang

[Peter Collingbourne]

On Wed, Feb 20, 2013 at 08:23:34PM -0800, John McCall wrote:
> On Feb 20, 2013, at 8:08 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> > On Wed, Feb 20, 2013 at 7:52 PM, John McCall <rjmccall at apple.com> wrote:
> > On Feb 20, 2013, at 7:49 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:
> > > On Wed, Feb 20, 2013 at 06:30:53PM -0800, John McCall wrote:
> > >> On Feb 20, 2013, at 6:24 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> > >>> On Wed, Feb 20, 2013 at 6:18 PM, John McCall <rjmccall at apple.com> wrote:
> > >>> On Feb 20, 2013, at 6:13 PM, Peter Collingbourne <peter at pcc.me.uk> 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