| Message ID | c313895654437fe154e989a7d633cca2ccc710d8.1698914967.git.federico.serafini@bugseng.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [XEN] xen/lib: remove the overwrtitten string functions from x86 build | expand |
On 02.11.2023 11:21, Federico Serafini wrote: > Remove the generic implementation of memcpy(), memmove() and > memset() from the x86 build since a version written in asm is present. > This addesses violations of MISRA C:2012 Rule 8.6 ("An identifier with > external linkage shall have exactly one external definition"). Yet part of the purpose of the code in lib/ is specifically to be available as a (uniform) fallback. Nothing from the resulting lib.a is going to be linked into the final Xen binaries, so I consider Eclair wrong (in some way at least) to view such symbols as having multiple definitions. Furthermore, if we really wanted to do conditional building like this, then what to exclude would want to be determined dynamically, such that it won't be necessary to keep two (or more) pieces of code in sync. Jan
On 02/11/2023 10:21 am, Federico Serafini wrote: > Remove the generic implementation of memcpy(), memmove() and > memset() from the x86 build since a version written in asm is present. > This addesses violations of MISRA C:2012 Rule 8.6 ("An identifier with > external linkage shall have exactly one external definition"). > > Signed-off-by: Federico Serafini <federico.serafini@bugseng.com> As I said on one of the previous calls, this is an error in analysis, not a bug in Xen. The behaviour when linking a library is well defined by the toolchain. Disassemble the final hypervisor and observe that there really is only one implementation, and it's always the arch-optimised version when both exist. ~Andrew
On Thu, 2 Nov 2023, Andrew Cooper wrote: > On 02/11/2023 10:21 am, Federico Serafini wrote: > > Remove the generic implementation of memcpy(), memmove() and > > memset() from the x86 build since a version written in asm is present. > > This addesses violations of MISRA C:2012 Rule 8.6 ("An identifier with > > external linkage shall have exactly one external definition"). > > > > Signed-off-by: Federico Serafini <federico.serafini@bugseng.com> > > As I said on one of the previous calls, this is an error in analysis, > not a bug in Xen. > > The behaviour when linking a library is well defined by the toolchain. > Disassemble the final hypervisor and observe that there really is only > one implementation, and it's always the arch-optimised version when both > exist. This is done automatically by linker, right? I am asking because I was curious and searching through the build system but couldn't find a specific place where the dropping of the lib implementation of things is done.
On 02/11/2023 10:23 pm, Stefano Stabellini wrote: > On Thu, 2 Nov 2023, Andrew Cooper wrote: >> On 02/11/2023 10:21 am, Federico Serafini wrote: >>> Remove the generic implementation of memcpy(), memmove() and >>> memset() from the x86 build since a version written in asm is present. >>> This addesses violations of MISRA C:2012 Rule 8.6 ("An identifier with >>> external linkage shall have exactly one external definition"). >>> >>> Signed-off-by: Federico Serafini <federico.serafini@bugseng.com> >> As I said on one of the previous calls, this is an error in analysis, >> not a bug in Xen. >> >> The behaviour when linking a library is well defined by the toolchain. >> Disassemble the final hypervisor and observe that there really is only >> one implementation, and it's always the arch-optimised version when both >> exist. > This is done automatically by linker, right? I am asking because I was > curious and searching through the build system but couldn't find a > specific place where the dropping of the lib implementation of things is > done. It's a property of linking, yes. There is a specified order that libraries are searched (L->R on the cmdline, IIRC) and the first object in a library to provide the symbol is the object that gets linked in. There are corner cases where you can pull in unrelated code and end up with multiple symbols of the same name, and this is explicitly mitigated by having one (public) function per object file wihtin the libs. ~Andrew
diff --git a/xen/lib/Makefile b/xen/lib/Makefile index 2d9ebb945f..ac0edd4745 100644 --- a/xen/lib/Makefile +++ b/xen/lib/Makefile @@ -1,5 +1,9 @@ obj-$(CONFIG_X86) += x86/ +ifneq ($(CONFIG_X86),y) + NO_ARCH_STRING_C=y +endif + lib-y += bsearch.o lib-y += ctors.o lib-y += ctype.o @@ -7,9 +11,9 @@ lib-y += list-sort.o lib-y += memchr.o lib-y += memchr_inv.o lib-y += memcmp.o -lib-y += memcpy.o -lib-y += memmove.o -lib-y += memset.o +lib-$(NO_ARCH_STRING_C) += memcpy.o +lib-$(NO_ARCH_STRING_C) += memmove.o +lib-$(NO_ARCH_STRING_C) += memset.o lib-y += muldiv64.o lib-y += parse-size.o lib-y += rbtree.o
Remove the generic implementation of memcpy(), memmove() and memset() from the x86 build since a version written in asm is present. This addesses violations of MISRA C:2012 Rule 8.6 ("An identifier with external linkage shall have exactly one external definition"). Signed-off-by: Federico Serafini <federico.serafini@bugseng.com> --- xen/lib/Makefile | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)