[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 3/4] xen/arm: domain: Fix MISRA C 2012 Rule 8.7 violation


  • To: Xenia Ragiadakou <burzalodowa@xxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 25 Jul 2022 08:32:41 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LEMI1NFGV6V7jkH+IAFDlcLl0okeZTCi4Cw6X6lc1MY=; b=UlCFlntDWFZ1+chK77SBfTd2BIxJqgUk9JvEQgaORGqnSubZGS7P5i0BhFITLJvqVACKS5wWswf7QjEhb4dDy8nida4b5jBjvVcvY8ktlEgI/KVdGLBRfijUTWmdqKWhrZmBX57UsPpdsCDW6FhIh1PIR4Vz2dmPWI9uxP+huoaGX2/ar6INOT4sRBmIFrBFNkcpzLSJlmCdwZ6Dq69FO+sczlI4jcclmXGPhmzLWAxl8IA4f+JwzsPle2asOyexlqlEmpy4D1UmHfH2R14kgk46/vnGjhlvvL8UFjR/YLljrI2W/5XuDrgqt/3m+BncP+QyR20h5vp2k1eKqFzK6w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Tz+yJLbimhojX5eswuLVT6xT97tGSaYiiEKBMzEPw7/WsLJxwuF/LDWk5BD0g4GeE3/IcrFkHoepqKpg8TfP7Ar55MLnmXtnTueyQb6WjusM/FvDjHf+0qNbR38Dj00t+upO9Ib3j7ljhiIsZzA/o1DYotFDALSIVBzcPRtCyr1huneGw6LWKrg//KBS8UP5/OGp/ApYtSOKOBLBO260BFXadrq2PTKfFeQm0vODq/7LK7IPp3zgpk95fOc06A+LJksu7Xa9Jxic7yrPdEqXT/RMZHSDW8Hyr02/OjrQZeb9qWPGZ2mVDTUxqepKIqFhwwpzDyZTU4lx3uGQWQ73vg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 25 Jul 2022 06:33:05 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 24.07.2022 19:20, Xenia Ragiadakou wrote:
> On 7/7/22 10:55, Jan Beulich wrote:
>> On 07.07.2022 09:27, Xenia Ragiadakou wrote:
>>> On 7/6/22 11:51, Jan Beulich wrote:
>>>> On 06.07.2022 10:43, Xenia Ragiadakou wrote:
>>>>> On 7/6/22 10:10, Jan Beulich wrote:
>>>>>> On 05.07.2022 23:02, Xenia Ragiadakou wrote:
>>>>>>> The function idle_loop() is referenced only in domain.c.
>>>>>>> Change its linkage from external to internal by adding the storage-class
>>>>>>> specifier static to its definitions.
>>>>>>>
>>>>>>> Since idle_loop() is referenced only in inline assembly, add the 'used'
>>>>>>> attribute to suppress unused-function compiler warning.
>>>>>>
>>>>>> While I see that Julien has already acked the patch, I'd like to point
>>>>>> out that using __used here is somewhat bogus. Imo the better approach
>>>>>> is to properly make visible to the compiler that the symbol is used by
>>>>>> the asm(), by adding a fake(?) input.
>>>>>
>>>>> I 'm afraid I do not understand what do you mean by "adding a fake(?)
>>>>> input". Can you please elaborate a little on your suggestion?
>>>>
>>>> Once the asm() in question takes the function as an input, the compiler
>>>> will know that the function has a user (unless, of course, it finds a
>>>> way to elide the asm() itself). The "fake(?)" was because I'm not deeply
>>>> enough into Arm inline assembly to know whether the input could then
>>>> also be used as an instruction operand (which imo would be preferable) -
>>>> if it can't (e.g. because there's no suitable constraint or operand
>>>> modifier), it still can be an input just to inform the compiler.
>>>
>>> According to the following statement, your approach is the recommended one:
>>> "To prevent the compiler from removing global data or functions which
>>> are referenced from inline assembly statements, you can:
>>> -use __attribute__((used)) with the global data or functions.
>>> -pass the reference to global data or functions as operands to inline
>>> assembly statements.
>>> Arm recommends passing the reference to global data or functions as
>>> operands to inline assembly statements so that if the final image does
>>> not require the inline assembly statements and the referenced global
>>> data or function, then they can be removed."
>>>
>>> IIUC, you are suggesting to change
>>> asm volatile ("mov sp,%0; b " STR(fn) : : "r" (stack) : "memory" )
>>> into
>>> asm volatile ("mov sp,%0; b %1" : : "r" (stack), "S" (fn) : "memory" );
>>
>> Yes, except that I can't judge about the "S" constraint.
>>
> 
> This constraint does not work for arm32. Any other thoughts?
> 
> Another way, as Jan suggested, is to pass the function as a 'fake' 
> (unused) input.
> I 'm suspecting something like the following could work
> asm volatile ("mov sp,%0; b " STR(fn) : : "r" (stack), "X" (fn) : "memory")
> What do you think?

Well, yes, X should always be a fallback option. But I said already when
you suggested S that I can't judge about its use, so I guess I'm the
wrong one to ask. Even more so that you only say "does not work", without
any details ...

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.