[PATCH] Add support for coldcc to clang

[Richard Smith]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130220/0de0e98b/attachment.html>