[llvm-dev] what are the rules about ssp function attributes?

[Andrew Kelley via llvm-dev]

On 12/16/20 4:06 PM, Fāng-ruì Sòng wrote:
> LangRef needs to be clarified. Sent https://reviews.llvm.org/D93422
> 

Thanks for the improved docs!

> 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?

Here is the zig code in question:

fn llshl(r: []Limb, a: []const Limb, shift: usize) void {
     @setRuntimeSafety(debug_safety);
...
         r[dst_i] = carry | @call(.{ .modifier = .always_inline }, 
math.shr, .{
...


So we have an "always inline" call from a function which has runtime 
safety disabled. Currently, having runtime safety off for a function 
means that it does not get "sspstrong" attribute.

In this particular code snippet the ideal behavior from zig's 
perspective would be if LLVM allowed the always_inline without the ssp 
attribute, and then did the thing that the new docs mention:

 > If a function with
 > the ``sspstrong`` attribute is inlined into a function with the
 > ``ssp`` attribute, the attribute in the caller will upgrade to
 > ``sspstrong``.

Otherwise, Zig will need to keep track of callees and then recursively 
figure out whether an inline call prevents omitting stack protection 
attributes. Doable, but repeating the work the LLVM pass is already doing.

> 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).

Wait a minute though, I don't understand why this needs to be the case. 
If a caller without ssp inlines a callee with it, then it seems to me 
that it should remove the ssp attribute from the callee at the callsite.

The %gs/Linux thing makes it sound like ssp is an ABI guarantee rather 
than a safety mechanism.

I suppose "always inline" should be implemented by zig itself before 
generating LLVM IR, and then it will get to decide how inlining works.

Anyway, thanks for your time and for the information.
Andrew

> 
> 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.
> 

-------------- 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/f54f4a1c/attachment.sig>