(Sorry about the duplicate, I got the mailing list address incorrect the first time around). While working on the IAS, I ran into a behavioural difference between GCC and clang. The Linux Kernel relies on GCC's acceptance of inline assembly as an opaque object which will not have any validation performed on the content. The current behaviour in LLVM is to perform validation of the contents by means of parsing the input if the MC layer can handle it. When compiling to an object file, this distinction is unimportant since the assembler will have to parse the content anyways. However, the case where the emission is an assembly file (as used by the Linux kernel) is something which needs to be discussed. The current options include: - continuing with the current behaviour (the user can disable the IAS even when assembling (-S) if necessary - behaving more like GCC and disabling the validation - introducing a new flag (-W{no-,}inline-asm-syntax ?) to control the behaviour - relaxing all errors to warnings Personally, I think that the LLVM model is better since it allows for earlier diagnosis of errors. But, I am torn between options 1 and 3 and could be easily convinced that either is better. This is sufficiently controversial that it deserves a separate thread of conversation. Thanks! -- Saleem Abdulrasool compnerd (at) compnerd (dot) org -------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.llvm.org/pipermail/llvm-dev/attachments/20140221/7922e4ab/attachment.html>
On 21 February 2014 11:22, Saleem Abdulrasool <compnerd at compnerd.org> wrote:> (Sorry about the duplicate, I got the mailing list address incorrect the > first time around). > > While working on the IAS, I ran into a behavioural difference between GCC > and clang. > > The Linux Kernel relies on GCC's acceptance of inline assembly as an opaque > object which will not have any validation performed on the content. The > current behaviour in LLVM is to perform validation of the contents by means > of parsing the input if the MC layer can handle it. > > When compiling to an object file, this distinction is unimportant since the > assembler will have to parse the content anyways. However, the case where > the emission is an assembly file (as used by the Linux kernel) is something > which needs to be discussed. > > The current options include: > - continuing with the current behaviour (the user can disable the IAS even > when assembling (-S) if necessary > - behaving more like GCC and disabling the validation > - introducing a new flag (-W{no-,}inline-asm-syntax ?) to control the > behaviour > - relaxing all errors to warnings > > Personally, I think that the LLVM model is better since it allows for > earlier diagnosis of errors. But, I am torn between options 1 and 3 and > could be easily convinced that either is better. > > This is sufficiently controversial that it deserves a separate thread of > conversation. > > Thanks!My preference is also for the first option. The files we reject now with -S are the ones we used to reject with -c. We just ask for "-S -no-integrated-as" to be used when a file contains invalid inline assembly. If that is too strict to work in practice, I think the alternatives I would prefer would be * Have the driver pass -no-integrated-as when given -S but not -integrated-as. That is, -no-integrated-as is always the default for -S in clang. This has the big advantage that parsing assembly is still just a on/off switch. * Have a second TargetOption: StrictIntegratedAS. Have the driver set that based on -S/-c and -integrated-as/-no-integrated-as. With this option we downgrade assembly parsing errors to warnings and fallback to EmitRawText, but without ever calling hasRawTextSupport. I believe this is equivalent to Renato's proposal. Even if we decide to go with the option of downgrading errors to warnings, we should probably still do that in a second step and first just have the driver disable the integrated assembler with -S for now. Cheers, Rafael
There was another option mentioned on the gcc mailing list: Pass comments through to the output. The current behaviour is to remove them. I prefer either 'continuing with the current behaviour' or 'current behaviour but report parse errors as warnings for -S'. I'd prefer the former of these two but I'm pushed away from that position by the fact that gas and IAS development aren't synchronised. Sometimes gas will support an instruction set that IAS hasn't implemented yet and I can imagine autoconf/cmake/etc. build systems using 'clang -S' and 'as' together even when the IAS is enabled by default. Ideally, we'd like a diagnostic to encourage bug reports for things we missed, but equally the user also doesn't want the build to fail due to deficiencies in IAS if gas is going to be the one to assemble it. Regarding the Linux kernel's use of inline assembly for arbitrary text. My starting position at least is that inline assembly is intended for valid assembly text. We could support near-arbitrary text without sacrificing that position by passing comments through to the assembly output. The kernel would have to add the comment characters (which vary between targets) and remove them again in its post-processing though.> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Rafael Espíndola > Sent: 21 February 2014 16:30 > To: Saleem Abdulrasool > Cc: LLVM Developers Mailing List > Subject: Re: [LLVMdev] IAS and inline assembly > > On 21 February 2014 11:22, Saleem Abdulrasool <compnerd at compnerd.org> > wrote: > > (Sorry about the duplicate, I got the mailing list address incorrect > > the first time around). > > > > While working on the IAS, I ran into a behavioural difference between > > GCC and clang. > > > > The Linux Kernel relies on GCC's acceptance of inline assembly as an > > opaque object which will not have any validation performed on the > > content. The current behaviour in LLVM is to perform validation of > > the contents by means of parsing the input if the MC layer can handle it. > > > > When compiling to an object file, this distinction is unimportant > > since the assembler will have to parse the content anyways. However, > > the case where the emission is an assembly file (as used by the Linux > > kernel) is something which needs to be discussed. > > > > The current options include: > > - continuing with the current behaviour (the user can disable the IAS > > even when assembling (-S) if necessary > > - behaving more like GCC and disabling the validation > > - introducing a new flag (-W{no-,}inline-asm-syntax ?) to control the > > behaviour > > - relaxing all errors to warnings > > > > Personally, I think that the LLVM model is better since it allows for > > earlier diagnosis of errors. But, I am torn between options 1 and 3 > > and could be easily convinced that either is better. > > > > This is sufficiently controversial that it deserves a separate thread > > of conversation. > > > > Thanks! > > My preference is also for the first option. The files we reject now with -S are > the ones we used to reject with -c. We just ask for "-S -no-integrated-as" to > be used when a file contains invalid inline assembly. If that is too strict to > work in practice, I think the alternatives I would prefer would be > > * Have the driver pass -no-integrated-as when given -S but not -integrated- > as. That is, -no-integrated-as is always the default for -S in clang. This has the > big advantage that parsing assembly is still just a on/off switch. > * Have a second TargetOption: StrictIntegratedAS. Have the driver set that > based on -S/-c and -integrated-as/-no-integrated-as. With this option we > downgrade assembly parsing errors to warnings and fallback to EmitRawText, > but without ever calling hasRawTextSupport. I believe this is equivalent to > Renato's proposal. > > Even if we decide to go with the option of downgrading errors to warnings, > we should probably still do that in a second step and first just have the driver > disable the integrated assembler with -S for now. > > Cheers, > Rafael > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu llvm.cs.uiuc.edu > lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Fri, Feb 21, 2014 at 8:29 AM, Rafael Espíndola < rafael.espindola at gmail.com> wrote:> My preference is also for the first option. The files we reject now > with -S are the ones we used to reject with -c. We just ask for "-S > -no-integrated-as" to be used when a file contains invalid inline > assembly. >Emphatic agreement.> If that is too strict to work in practice, I think the > alternatives I would prefer would be > > * Have the driver pass -no-integrated-as when given -S but not > -integrated-as. That is, -no-integrated-as is always the default for > -S in clang. This has the big advantage that parsing assembly is still > just a on/off switch. > * Have a second TargetOption: StrictIntegratedAS. Have the driver set > that based on -S/-c and -integrated-as/-no-integrated-as. With this > option we downgrade assembly parsing errors to warnings and fallback > to EmitRawText, but without ever calling hasRawTextSupport. I believe > this is equivalent to Renato's proposal. > > Even if we decide to go with the option of downgrading errors to > warnings, we should probably still do that in a second step and first > just have the driver disable the integrated assembler with -S for now. >I don't much like any of these options. I actually have strong objections to essentially all of the suggestions outside of the current state except for passing comments through. I think passing comments through seems obvious and correct. I also don't think it makes any difference for hacks like the one being used by the linux kernel, so while it seems fine in general, it doesn't seem important for this use case. I think the simple reality is that if you want to use inline assembly to dump raw text around C code to an assembly file generated with -S, turn off the integrated assembler entirely. You clearly don't want it. -------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.llvm.org/pipermail/llvm-dev/attachments/20140221/5748856e/attachment.html>