Update ECLAIR configuration to take into account the standard search
procedure adopted by Unix linkers.

Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index d8170106b4..43648232aa 100644
--- 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
+
+
 -doc_begin="The gnu_inline attribute without static is deliberately allowed."
 -config=MC3R1.R8.10,declarations+={deliberate,"property(gnu_inline)"}
 -doc_end
-- 
2.34.1

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.

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).

> +
> +

Nit: No double blank lines please.

Jan

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/*".


> 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".

-- 
Federico Serafini, M.Sc.

Software Engineer, BUGSENG (http://bugseng.com)

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