Add a new directive .variant_cc for variant calling conventions.

[Hsiangkai]

No description provided.

[ebahapo]

Instead of a new directive, perhaps a new .type argument would make more sense, since functions typically take a .type to be specified as function symbols.

[Hsiangkai]

Instead of a new directive, perhaps a new .type argument would make more sense, since functions typically take a .type to be specified as function symbols.

ARM defines a new directive, .variant_pcs, for the purpose. Should we extend the syntax of .type?

• https://sourceware.org/binutils/docs/as/AArch64-Directives.html
• https://reviews.llvm.org/D89138

[kito-cheng]

@jim-wilson @jrtc27

[kito-cheng]

LGTM.

[jim-wilson]

We shouldn't invent anything new if we don't have to. .variant_cc is consistent with the aarch64 port. This looks good to me.

[kito-cheng]

@asb @jrtc27 @luismarques @MaskRay

This PR is related to Calling conventions for the lazily bound functions. riscv-non-isa/riscv-elf-psabi-doc#190, used to mark a symbol is STO_RISCV_VARIANT_CC, and do not lazy binding for this symbol.

I guess there is no much controversy here since the solution just same as AArch64, but I would like to got some LGTM from LLVM community.

[asb]

@asb @jrtc27 @luismarques @MaskRay

This PR is related to Calling conventions for the lazily bound functions. riscv/riscv-elf-psabi-doc#190, used to mark a symbol is STO_RISCV_VARIANT_CC, and o not lazy binding for this symbol.

I guess there is no much controversy here since the solution just same as AArch64, but I would like to got some LGTM from LLVM community.

I've got no objections, but I'd defer to @MaskRay on this one.

[MaskRay]

(@asb Thanks for the trust:) )

LGTM (I don't have github permission to approve).

Using a new directive (not reusing .type) has the following advantages beside following aarch64's lead:

• .type is for st_type. st_other is orthogonal to st_type. (gnu_unique_object was an unfortunate anti-example.)
• compilers don't set .type for undefined symbols, but .variant_cc is needed at reference site for correctness.
• avoid overriding the generic .type with arch-specific semantics.

I assume that we cannot reuse .variant_pcs because PCS is an aarch64 term...
A new directive theoretically allows extension without introducing user confusion, though it may be hard to think how .variant_cc could be extended in the future. (One possibility is to allow .variant_cc a, b, c but aarch64 doesn't support it, either; and this doesn't seem too useful anyway.)

The subject should be changed. "bind now " seems outdated. Ideally just mention the directive name .variant_cc in the subject. It makes log digging easier in the future.

[kito-cheng]

@jim-wilson @aswaterman could you merge this PR? I believe we reached a consensus between LLVM and GNU toolchain folks, and the psabi spec merged too, riscv-non-isa/riscv-elf-psabi-doc#190

[jrtc27]

Commits should be squashed and reworded to not talk about bind now

[Hsiangkai]

Commits are squashed and the title is changed. Sorry for the late update.