From mboxrd@z Thu Jan  1 00:00:00 1970
From: Julien Grall <julien.grall@linaro.org>
Subject: Re: [PATCH 02/34] xen: clang: Disable built-in assembler
Date: Tue, 01 Apr 2014 16:52:30 +0100
Message-ID: <533AE0BE.8010307@linaro.org>
References: <1395766541-23979-1-git-send-email-julien.grall@linaro.org>
	<1395766541-23979-3-git-send-email-julien.grall@linaro.org>
	<5332CDE00200007800002490@nat28.tlf.novell.com>
	<20140326131625.GB7885@deinos.phlegethon.org>
	<5332ED80.5070305@linaro.org>
	<533300BC02000078000027D4@nat28.tlf.novell.com>
	<20140327180134.GN91759@deinos.phlegethon.org>
	<53374F57.6070100@linaro.org>
	<1396357870.8667.167.camel@kazak.uk.xensource.com>
	<533AD21E.1060809@linaro.org>
	<1396366117.8667.241.camel@kazak.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@linaro.org>) id 1WV0zK-0008Hu-2e
	for xen-devel@lists.xenproject.org; Tue, 01 Apr 2014 15:52:34 +0000
Received: by mail-we0-f174.google.com with SMTP id t60so6427340wes.19
	for <xen-devel@lists.xenproject.org>;
	Tue, 01 Apr 2014 08:52:32 -0700 (PDT)
In-Reply-To: <1396366117.8667.241.camel@kazak.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel@lists.xenproject.org, stefano.stabellini@citrix.com, Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
List-Id: xen-devel@lists.xenproject.org

On 04/01/2014 04:28 PM, Ian Campbell wrote:
> On Tue, 2014-04-01 at 15:50 +0100, Julien Grall wrote:
>> On 04/01/2014 02:11 PM, Ian Campbell wrote:
>>> On Sat, 2014-03-29 at 22:55 +0000, Julien Grall wrote:
>>>> Hi Tim,
>>>>
>>>> On 27/03/14 18:01, Tim Deegan wrote:
>>>>>
>>>>> The patch below works for me (at least as far as building
>>>>> asm-offsets.h on x86) by wrapping everything in a string.  I did try
>>>>> just prefixing with '#' but clang 3.5 also strips the comments out.
>>>>> That seems unhelpful, since I know some people put comments in their
>>>>> inline assembler too. :(
>>>>
>>>> I'm able to build correctly x86 with your patch, and this patch (e.g #2) 
>>>> reverted.
>>>>
>>>> But for ARM ... it breaks in another place :(
>>>>
>>>> vfp.c:8:25: error: invalid operand for instruction
>>>>      v->arch.vfp.fpexc = READ_CP32(FPEXC);
>>>> <inline asm>:1:6: note: instantiated into assembly here
>>>>          mrc p10, 7, r1, c8, c0, 0;
>>>>              ^
>>>>
>>>> Coprocessor p10 (and p11) are used for Neon instruction are clang 
>>>> doesn't allow to use it directly. 
>>>> (http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131104/194170.html).
>>>>
>>>> Depends on which part of the ARM ARM you are reading, p10 and p11 should 
>>>> not be used directly with mrc/mcr instruction ... but gas accept it.
>>>>
>>>> I guess the best solution is to use directly the VFP instructions but it 
>>>> would mean to re-enable VFP at compile time in Xen (see 
>>>> http://www.gossamer-threads.com/lists/xen/devel/284653?do=post_view_threaded).
>>>
>>> Do the VFP instructions have different encodings? I thought this was an
>>> assembler mnemonic difference only.
>>
>> Strictly speaking it works only because vldm* as the same encoding as
>> ldc*. But the processor will decode the instruction as vldm* (and
>> execute as it is).
> 
> Are those the instructions in question though? The thing you quoted was
> about reading FPEXC which is an mrc cp instruction vs vmrs I think. They
> do indeed have identical encodings, so I'm not entirely sure what the
> big deal is about which assembler mnemonic gets used is, the process has
> no idea what we wrote in the source.

Oh sorry, I took one in random. Every VFP instructions has the same
issue. I will raise the bug to Clang. And see if why they choose this
solution.

-- 
Julien Grall