llvm dev - Dec 2020 - what are the rules about ssp function attributes?

Hello,

Zig is now tripping a new LLVM assert in recent main branch commits of LLVM:

Assertion failed: (!(!Caller.hasStackProtectorFnAttr() && 
Callee.hasStackProtectorFnAttr()) && "stack protected callee but
caller
requested no stack protector"), function adjustCallerSSPLevel, file 
/Users/kubkon/dev/llvm-project/llvm/lib/IR/Attributes.cpp, line 1951.

Caller is

; Function Attrs: nobuiltin nounwind
define internal fastcc void @std.math.big.int.llshl(%"[]usize"*
nonnull
readonly align 8 %0, %"[]usize"* nonnull readonly align 8 %1, i64 %2) 
unnamed_addr #2 !dbg !445894 {

Callee is

; Function Attrs: nobuiltin nounwind sspstrong
define internal fastcc i64 @std.math.shr.11603(i64 %0, i64 %1) 
unnamed_addr #1 !dbg !445958 {

So that's indeed a sspstrong function calling a non-sspstrong function. 
Why is that not allowed? The LLVM language reference makes it sound like 
you can have some functions protected and some functions not protected:

 > sspstrong
 >
 > This attribute indicates that the function should emit a stack 
smashing protector.
 > ...
 > If a function that has an sspstrong attribute is inlined into a
 > function that doesn’t have an sspstrong attribute, then the resulting
 > function will have an sspstrong attribute.

Can anyone shed some light on this?

Thanks in advance!
Andrew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201216/c697c214/attachment.sig>

LangRef needs to be clarified. Sent https://reviews.llvm.org/D93422

The behavior change was due to https://reviews.llvm.org/D91816 . How
does Zig end up merging the attributes
while the inliner blocks such inlining?

If a caller without ssp inlines a callee with ssp:
  the caller may alter %gs for its own purposes
  and will break the %gs usage in the callee.
(This one is required by the Linux kernel).

If a ssp caller inlines a callee without ssp:
  This one is a bit unclear to me why it needs to have such semantics,
probably because
  the callee expresses an intention (no ssp) and the caller should respect it.

On Wed, Dec 16, 2020 at 1:43 PM Andrew Kelley via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Hello,
>
> Zig is now tripping a new LLVM assert in recent main branch commits of
LLVM:
>
> Assertion failed: (!(!Caller.hasStackProtectorFnAttr() &&
> Callee.hasStackProtectorFnAttr()) && "stack protected callee
but caller
> requested no stack protector"), function adjustCallerSSPLevel, file
> /Users/kubkon/dev/llvm-project/llvm/lib/IR/Attributes.cpp, line 1951.
>
> Caller is
>
> ; Function Attrs: nobuiltin nounwind
> define internal fastcc void @std.math.big.int.llshl(%"[]usize"*
nonnull
> readonly align 8 %0, %"[]usize"* nonnull readonly align 8 %1, i64
%2)
> unnamed_addr #2 !dbg !445894 {
>
> Callee is
>
> ; Function Attrs: nobuiltin nounwind sspstrong
> define internal fastcc i64 @std.math.shr.11603(i64 %0, i64 %1)
> unnamed_addr #1 !dbg !445958 {
>
> So that's indeed a sspstrong function calling a non-sspstrong function.
> Why is that not allowed? The LLVM language reference makes it sound like
> you can have some functions protected and some functions not protected:
>
>  > sspstrong
>  >
>  > This attribute indicates that the function should emit a stack
> smashing protector.
>  > ...
>  > If a function that has an sspstrong attribute is inlined into a
>  > function that doesn’t have an sspstrong attribute, then the resulting
>  > function will have an sspstrong attribute.
>
> Can anyone shed some light on this?
>
> Thanks in advance!
> Andrew
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


-- 
宋方睿