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

Re: Xen reliance on non-standard GCC features


  • To: Michal Orzel <michal.orzel@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 9 Jun 2023 14:18:18 +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=6ObMLwA7V1HyG/B2tHduxJWUbzB50EudVKLfou/mcIU=; b=ntyn/99FPalzpROdogbI/3L43PpWORSF4iJDaKbgO965UxRFNu4flrLczWGQCK1g6PtYaPGrbG0GXjqoFJwfXcGg1Z6wQMyzSwK8NEUqdTtOq4xjX3O5OMPdt8A5txECl+58e4goOu3/THbQLpXSMmNDeQIGcJy7FiY5uYdfY5aR8eIOx/G985HKblcUD+1e0400dcIXXmKSnwJywZUaR6gMvU0OlADpr7TK7D9BSWqD6OLFxs2x3Y7UyU2GKKkchH45rxdUNEP1p3xn/j/kpDFM57vLel5I3NQGKRdGjV7C/2ED1zSe5sVyusOy0+7nJa8iHQMzb5ENXwitUgYlfA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OyMbpwGwX0oxnY/zjzt92U6skBLv/FsIFQLBmWqX0TGiRL8HxYmIAJzI/54yH5+6C2UlBGT8uAn6PybjInUgChoPsRN1lQ39LXKTGFuL8Ekx3a3qMWk+k6egclE3hlXshhGQe2UhMelFd+njI+K0QXNkykh5FSFPkYOAJTtWyBzv8DkDNKPg+GCQ6RW9DM3E3THI5L4dJxml1hAkkmxKIbXaK2wY0oH087ZwmLkUzi/y/636gWWa4JBPvFUEjdwbWPXtFV8dJXOxK+VtAppTYZpFfJZaTAPJ2ML3JOMPHgjR+QQRbjU7l8GWcgAjdrYFa1OhIKnwelkvJrTz+guyjQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Stefano Stabellini <stefano.stabellini@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "consulting@xxxxxxxxxxx" <consulting@xxxxxxxxxxx>, Roberto Bagnara <bagnara@xxxxxxxxxxx>
  • Delivery-date: Fri, 09 Jun 2023 12:18:31 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 09.06.2023 12:12, Michal Orzel wrote:
> 
> 
> On 09/06/2023 11:47, Jan Beulich wrote:
>>
>>
>> On 09.06.2023 11:36, Michal Orzel wrote:
>>> On 09/06/2023 10:54, Jan Beulich wrote:
>>>> On 08.06.2023 14:18, Roberto Bagnara wrote:
>>>>> On 07/06/23 09:39, Jan Beulich wrote:
>>>>>> On 05.06.2023 15:26, Roberto Bagnara wrote:
>>>>>>> On 05/06/23 11:28, Jan Beulich wrote:
>>>>>>>> On 05.06.2023 07:28, Roberto Bagnara wrote:
>>>>>>>>> U6) Empty declarations.
>>>>>>>
>>>>>>> Examples:
>>>>>>>
>>>>>>> xen/arch/arm/arm64/lib/find_next_bit.c:57.29:
>>>>>>> empty declaration (ill-formed for the C99 standard, ISO/IEC 9899:1999 
>>>>>>> Section 6.7: "An empty declaration." [STD.emptdecl]). Tool used is 
>>>>>>> `/usr/bin/aarch64-linux-gnu-gcc-12'
>>>>>>>
>>>>>>> xen/arch/arm/arm64/lib/find_next_bit.c:103.34:
>>>>>>> empty declaration (ill-formed for the C99 standard, ISO/IEC 9899:1999 
>>>>>>> Section 6.7: "An empty declaration." [STD.emptdecl]). Tool used is 
>>>>>>> `/usr/bin/aarch64-linux-gnu-gcc-12'
>>>>>>
>>>>>> Looks like these could be taken care of by finally purging our
>>>>>> EXPORT_SYMBOL() stub.
>>>>>>
>>>>>>> xen/arch/arm/include/asm/vreg.h:143.26:
>>>>>>> empty declaration (ill-formed for the C99 standard, ISO/IEC 9899:1999 
>>>>>>> Section 6.7: "An empty declaration." [STD.emptdecl]). Tool used is 
>>>>>>> `/usr/bin/aarch64-linux-gnu-gcc-12'
>>>>>>>
>>>>>>> xen/arch/arm/include/asm/vreg.h:144.26:
>>>>>>> empty declaration (ill-formed for the C99 standard, ISO/IEC 9899:1999 
>>>>>>> Section 6.7: "An empty declaration." [STD.emptdecl]). Tool used is 
>>>>>>> `/usr/bin/aarch64-linux-gnu-gcc-12'
>>>>>>
>>>>>> I'm having trouble spotting anything suspicious there.
>>>>>
>>>>> The macro expands to definitions of inline functions
>>>>> and after the macro invocation there is a ";".
>>>>>
>>>>> The preprocessed code is then:
>>>>>
>>>>> static inline void foo() { ... }
>>>>> ;
>>>>>
>>>>> where the final ";" is an empty declaration not allowed by
>>>>> the C99 language standard.
>>>>
>>>> Oh, I see.
>>>>
>>>>> Removing the ";" after the macro invocation is a possible solution,
>>>>> but other possibilities exist if this is strongly unwanted.
>>>>
>>>> We have other macros to instantiate functions, and there no stray
>>>> semicolons are used. I think this wants doing the same way here, but it
>>>> being Arm code the ultimate say is with the Arm maintainers.
>>> Apart from vreg.h the same applies to TLB_HELPER of arm32/arm64.
>>> I think also TYPE_SAFE would want to be fixed.
>>
>> Indeed. For this last one I wonder though whether it wouldn't be better
>> to continue to permit (really: require) the semicolon at the use sites,
>> by putting the typedef-s last and omitting the semicolon in the macro
>> definitions.
> This would be an error I think since the functions are defined using this type
> so it must be defined first. Unless there is a way to forward typedef.

Well, I didn't make the suggestion without first checking whether that
would (likely) be possible.

> All in all,
> removing semicolon at use sites is simpler.

Simpler - yes. But syntax-wise I think it is best if, except in special
cases, kind-of-statements and kind-of-declarations ended with a semicolon.
Special cases would be in particular ones where macro definition and
macro use are next to one another.

Jan



 


Rackspace

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