[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
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |