Re: [Xen-devel] [PATCH 02/34] xen: clang: Disable built-in assembler

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.03.14 at 16:08, <julien.grall@xxxxxxxxxx> wrote:
> Hi Tim,
> 
> On 03/26/2014 01:16 PM, Tim Deegan wrote:
>> At 11:53 +0000 on 26 Mar (1395831232), Jan Beulich wrote:
>>>>>> On 25.03.14 at 17:55, <julien.grall@xxxxxxxxxx> wrote:
>>>> --- a/xen/Rules.mk
>>>> +++ b/xen/Rules.mk
>>>> @@ -74,6 +74,7 @@ AFLAGS-y                += -D__ASSEMBLY__ -include 
>>>> $(BASEDIR)/include/xen/config
>>>>  
>>>>  # Clang's built-in assembler can't handle .code16/.code32/.code64 yet
>>>>  AFLAGS-$(clang)         += -no-integrated-as
>>>> +CFLAGS-$(clang)         += -no-integrated-as
>>>
>>> Iirc Tim had found and worked around other built-in assembler issues
>>> in the past, so if this is to be done unconditionally I wonder whether
>>> we shouldn't then drop those workarounds.
>> 
>> I would prefer, wherever possible, to make things work with the clang
>> assembler rather than rely on the binutils one forever.
> 
> The clang integrated assembler is too powerful for some part of Xen :).
> Every inline assembly code is parsing by the assembler to check the syntax.
> 
> This will result to failure to generate asm-offsets.c because of the ->
> in the code (see arch/arm/arm32/asm-offsets.c: DEFINE/BLANK macros).
> Indeed, the -> is not a valid assembler syntax.

But what business does the compiler have to pass the assembly
code to its internal assembler when all it was asked was to output
assembly? That may be acceptable as an optional internal
consistency check (verifying the compiler produced valid assembly),
but shouldn't constrain the user from using the compiler for things
where it's known the output isn't going to be valid assembly.

That said, I think it wouldn't be too difficult to change the
asm-offsets logic to produce something that does look like valid
assembly.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel