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

[Jan Beulich <jbeulich@xxxxxxxx>]

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