Re: clang asm-goto support (Was Re: [PATCH v2] x86/retpoline: Add clang support)

[James Y Knight]

I'd be definitely in favor having clang support asm goto. I wouldn't
want to exclude having other conversations about how to more directly
provide compiler features that the linux kernel could use, ALSO, but I
do not think that conversation should block implementing asm-goto.

IMO, inline asm is, generally, a valuable feature to provide in the
compiler as an escape hatch, and asm goto is a relatively sane
extension of it. Supporting outgoing edges from an inline asm block is
a reasonable thing for users to desire, and as far as anyone's said so
far, seems like it ought to be fairly easily implementable, without
causing bad side-effects in the compiler.

Of course, we generally do want to minimize the need for users to use
inline asm, by providing appropriate compiler support for the features
people would otherwise be forced to implement using asm. But I don't
see that as really any more important for asm-goto than any other
inline asm. There will always be a desire for escape hatches, to do
weird and unique things which aren't supported directly in the
compiler. (Also, the kernel is a pretty special case in terms of its
requirements, it seems exceedingly unlikely that we could ever provide
enough compiler support to let it eliminate inline asm.).

On Wed, Feb 14, 2018 at 3:33 AM, Yatsina, Marina
<marina.yatsina@xxxxxxxxx> wrote:
>
> Hi Kees,
>
> When I raised the question of whether we want to add support for "asm goto" in llvm I got some feedback from the community that "asm goto" might not be the best solution for the problem it was invented for (optimizing support for tracepoints), so I stopped perusing this issue.
> I'm CC-ing the developers that participated in the original thread and a few developers that might be interested in adding support of "asm goto".
> I'm also adding the llvm-dev mailing list, in case there are additional parties interested in voicing their opinion.
>
> I hope this will give this issue a push forward and we will find a solution that will not prevent llvm from compiling linux kernel.
>
> Thanks,
> Marina
>
> -----Original Message-----
> From: Kees Cook [mailto:keescook@xxxxxxxxxx]
> Sent: Wednesday, February 14, 2018 02:29
> To: David Woodhouse <dwmw2@xxxxxxxxxxxxx>; Chandler Carruth <chandlerc@xxxxxxxxxx>; Yatsina, Marina <marina.yatsina@xxxxxxxxx>
> Cc: Guenter Roeck <linux@xxxxxxxxxxxx>; X86 ML <x86@xxxxxxxxxx>; LKML <linux-kernel@xxxxxxxxxxxxxxx>; Alan Cox <gnomes@xxxxxxxxxxxxxxxxxxx>; Rik van Riel <riel@xxxxxxxxxx>; Andi Kleen <ak@xxxxxxxxxxxxxxx>; Josh Poimboeuf <jpoimboe@xxxxxxxxxx>; Tom Lendacky <thomas.lendacky@xxxxxxx>; Peter Zijlstra <peterz@xxxxxxxxxxxxx>; Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>; Jiri Kosina <jikos@xxxxxxxxxx>; Andy Lutomirski <luto@xxxxxxxxxxxxxx>; Hansen, Dave <dave.hansen@xxxxxxxxx>; Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>; Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxxx>; Paul Turner <pjt@xxxxxxxxxx>; Stephen Hines <srhines@xxxxxxxxxx>; Nick Desaulniers <ndesaulniers@xxxxxxxxxx>
> Subject: clang asm-goto support (Was Re: [PATCH v2] x86/retpoline: Add clang support)
>
> On Tue, Feb 13, 2018 at 4:10 PM, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
> > We also need to resolve the asm-goto thing.
>
> Yes, this is becoming much more urgent, assuming we'll be raising the minimum GCC version soon and drop support for lacking asm-goto...
>
> Do you happen to know who the right people are to include to move the discussion forward? I know various kernel folks that are passionate about it, but I'm still getting to know who to talk with from llvm.
>
> I see an earlier thread here:
> http://lists.llvm.org/pipermail/llvm-dev/2017-April/111748.html
>
> It seems to end there? I'm still coming up to speed on it, so I'm likely missing other context.
>
> -Kees
>
> --
> Kees Cook
> Pixel Security
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.