| Message ID | 4de6c01f8af987750e578b3d5733dcd4ca536a9b.1699615143.git.federico.serafini@bugseng.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [XEN] automation/eclair: add a deviation for MISRA C:2012 Rule 8.6 | expand |
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".
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
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
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(+)