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

Re: [XEN PATCH] automation/eclair: add a deviation for MISRA C:2012 Rule 8.6


  • To: Federico Serafini <federico.serafini@xxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 13 Nov 2023 08:34:05 +0100
  • 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=cvFA9mQBKyyRZbN5UVnqD8Ge0EpTSq4ZkynkZUuWjc0=; b=WEGe7pURzHIUdvCRSygDkOJK3Cem3XLAJIDMq1nh6J4GxtG6ionc9oaY/W5R+JhBlYVOzTT9PFJQl8ljoXEf3ys+NVo5szCHL7/xXbJgAZjvs8lomP1R/IQJ2wXRBerZVzCTidVkkdfik3v9kK0oK5JwvUOdAiPlkXmwjddwZ2DFO2DRMrvJaNR6mL0P4GRM/sc0wE/cUw75oDSyNGlKFu/8VSoEx3q3OtobwUpziTzp5dOISFHhdgYihZ/SqFdoKS3rJmRAMhdC2boX8X7KcuyOYFhwsbA6hwR9/EN1peW+abGfLdtFF0W40srvaJU3NAgM7ajsHtRSrdSyjX5nzQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GoDywfOx8t2+R7p3pmdABxqNnngqJmlyf8UOtiKQmAuMbLStoA4ODbr/o4rCE9p5D/vM0/X+ViZYIB8gAb0Bi6MrD08bd65RuU/Oj6T31sI6JET3Jt5l1M4O89DGMSQEGp4Rmzy20t0ibLPNW/SGHxxjGXZZKDbJBHp2JnbiisdumpcXeZroEju3tFZme3rTEgMAKtCGuJN439vRqxedMfFUaIUkkEpRRVqOlmCBETr/Prm956wksDLdzlK8IcV9+DjA+rOtZS2NS8u++pC4vjsh584yzr+DCn61P9mqX464x974h9G0Rpuor9tnrGfPjo2SWFNfUXcrQYL+F8OBbQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: consulting@xxxxxxxxxxx, Simone Ballarin <simone.ballarin@xxxxxxxxxxx>, Doug Goldstein <cardoe@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 13 Nov 2023 07:34:51 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 10.11.2023 17:54, Federico Serafini wrote:
> On 10/11/23 13:41, Jan Beulich wrote:
>> On 10.11.2023 12:23, Federico Serafini wrote:
>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> @@ -214,6 +214,15 @@ definition is compiled-out or optimized-out by the 
>>> compiler)"
>>>   -config=MC3R1.R8.6,reports+={deliberate, "first_area(^.*has no 
>>> definition$)"}
>>>   -doc_end
>>>   
>>> +-doc_begin="For functions memcpy(), memmove() and memset(), if there are
>>> +multiple definitions, those belong to different archives and the behavior 
>>> of
>>> +linking is well defined by the toolchain: only one of the definitions will 
>>> be
>>> +linked in (the first that is encountered searching the archives in the 
>>> order
>>> +they appear on the command line)."
>>> +-config=MC3R1.R8.6,declarations+={deliberate, 
>>> "name(memcpy||memmove||memset)"}
>>> +-doc_end
>>
>> Why would this be limited to mem*()? Anything put into lib.a is going to
>> be treated like that.
> 
> If one day another arch-specific definition for a function will be
> introduced, a violation will appear but that is not necessarily a bad
> thing because it will lead to another check of the compilation scripts
> to ensure objects and archives are linked in the right order.
> However, if in your opinion this will be a waste of time,
> I can propose another deviation based on "xen/lib/*".

I think that's the route to go. As said, the whole purpose of xen/lib/'s
lib.a is to satisfy any "library" references which haven't been supplied
by other means.

>> The description also isn't quite accurate: Per-arch mem*() won't be put
>> in archives, but in .o files. Those are always linked in. Anything not
>> otherwise resolved may then be resolved by picking objects from
>> archives (appearing later on the command line, unless specially grouped).
> 
> What do you think of the following as justification:
> 
> The search procedure for Unix linkers is well defined, see ld(1) manual:
> "The linker will search an archive only once, at the location where it
> is specified on the command line. If the archive defines a symbol which
> was undefined in some object which appeared before the archive on the
> command line, the linker will include the appropriate file(s) from the
> archive."
> In Xen, thanks to the order in which file names appear in the build
> commands, if arch-specific definitions are present, they get always 
> linked in before searching in the lib.a archive resulting from
> "xen/lib".

Sounds much better to me, thanks.

Jan



 


Rackspace

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