release_33 branch patches

[Tom Stellard]

On Fri, Aug 30, 2013 at 09:13:06AM -0400, Brad Smith wrote:
> On 29/08/13 3:59 PM, Tom Stellard wrote:
> >On Thu, Aug 29, 2013 at 12:00:59PM -0400, Brad Smith wrote:
> >>Here are some patches I'd like to propose being merged to the 3.3 branch..
> >>
> >>For LLVM..
> >>
> >>r183533 | rafael | 2013-06-07 12:35:57 -0400 (Fri, 07 Jun 2013) | 12 lines
> >>
> >>Support OpenBSD's native frame protection conventions.
> >>
> >>OpenBSD's stack smashing protection differs slightly from other
> >>platforms:
> >>
> >>   1. The smash handler function is "__stack_smash_handler(const char
> >>      *funcname)" instead of "__stack_chk_fail(void)".
> >>
> >>   2. There's a hidden "long __guard_local" object that gets linked
> >>      into each executable and DSO.
> >>
> >>Patch by Matthew Dempsky.
> >>
> >
> >I think this patch will break ABI compatibility, since it adds a new
> >private member to the StackProtector class, so I don't think we can
> >merge it as is.  Does this patch only affect OpenBSD?  If so, then my
> >feeling is that it is OK with the ABI fixes, approval from the code owner,
> >and a volunteer who is willing to test the 3.3.1 release on OpenBSD.
> 
> Yes, it only affects OpenBSD. I can test this.
> 
> >>For Clang..
> >>
> >>r183295 | rafael | 2013-06-05 00:28:55 -0400 (Wed, 05 Jun 2013) | 3 lines
> >>
> >>Default to PIE and using stack protection on OpenBSD.
> >>
> >>Patch by Matthew Dempsky.
> >>
> >
> >I think the addition of the new option in Options.td will break the ABI,
> >also it seems to me like a new feature, so I'm not sure if this should
> >go in.  It would be good if the code owner or someone else could explain
> >exactly why this patch is important.
> 
> I don't understand what you mean by breaking the ABI when it comes
> to adding a command line parameter for the compiler driver. This
> commit is coupled with the commit above fixing the stack protector
> support. Anyway, the idea was for the point release to fix the
> OpenBSD support so building from src didn't require patching to have
> a proper working compiler.
> 

Modifying tablegen files can break the ABI in cases where tablegen is
generating public lookup tables, since the tables are usually sorted by
name, so adding something new may insert an item into the middle of the
table.  I'm not sure if this is what Options.td is used for though.

I know that requiring a stable ABI for point releases is rather strict,
but when stable releases were proposed a few people expressed their
preference for a stable ABI and no one objected.  I think it is too late
to change this policy for 3.3, but perhaps we could revisit it for 3.4.

-Tom