Linux: LTS 4.4 x86_64 builds failing `undefined reference to memcpy`

[nickdesaulniers]

vaguely similar to #650
Looks like the 4.4 builds for x86_64 started failing:
https://travis-ci.com/ClangBuiltLinux/continuous-integration/jobs/232287034

  LD      arch/x86/boot/compressed/vmlinux
ld.lld-10: error: undefined symbol: __memcpy

maybe a recent change to 4.4 caused this?

[nathanchance]

I went ahead and bisected. Haven't done any further triage, I'll have some more time tonight to do so.

# bad: [efbc4a364bd5469a616668127439e7cfca4c1d7b] Linux 4.4.191
# good: [5e9f4d704f8698b6d655afa7e9fac3509da253bc] Linux 4.4.190
git bisect start 'v4.4.191' 'v4.4.190'
# bad: [9e0b3406326401f4f7f1ce84194a29a595dc7aa9] vhost: introduce vhost_exceeds_weight()
git bisect bad 9e0b3406326401f4f7f1ce84194a29a595dc7aa9
# good: [114bf652fbb64f77eb99fa5eb7d7b78d9963e6d3] net: hisilicon: Fix dma_map_single failed on arm64
git bisect good 114bf652fbb64f77eb99fa5eb7d7b78d9963e6d3
# bad: [24a5ed6757d857bcbecd413ef592fb86f1c15231] x86/boot: Fix boot regression caused by bootparam sanitizing
git bisect bad 24a5ed6757d857bcbecd413ef592fb86f1c15231
# good: [74c6926bf9884befde60a432b8322db4ee364c4e] Revert "dm bufio: fix deadlock with loop device"
git bisect good 74c6926bf9884befde60a432b8322db4ee364c4e
# good: [35b67f4f1659a5fbbdf0d99447ae085de31a7a99] x86/retpoline: Don't clobber RFLAGS during CALL_NOSPEC on i386
git bisect good 35b67f4f1659a5fbbdf0d99447ae085de31a7a99
# bad: [41664b97f46e2c951c05313f4a9e9bb1fecc1439] x86/boot: Save fields explicitly, zero out everything else
git bisect bad 41664b97f46e2c951c05313f4a9e9bb1fecc1439
# good: [a0a0e3bf98fc3c0f13b669ea2a66995d677a2484] x86/apic: Handle missing global clockevent gracefully
git bisect good a0a0e3bf98fc3c0f13b669ea2a66995d677a2484
# first bad commit: [41664b97f46e2c951c05313f4a9e9bb1fecc1439] x86/boot: Save fields explicitly, zero out everything else

[ihalip]

I could see that clang added a reference to __memcpy in arch/x86/boot/compressed/misc.o, which is not present with GCC. The call to memcpy() in the commit pointed out by @nathanchance seems to cause this issue.

Tentative fix: https://gist.github.com/ihalip/f15b20f1a7e3e92f0268574c6b723dcf.

I'll look into why this doesn't happen with GCC once I have a little more time.

[ihalip]

This happens because clang pretends to be GCC 4.2.1. In this case, memcpy is a macro that gets expanded to a call to __memcpy, but none of the files in the linking step define it.

This doesn't happen in mainline because the GCC version check was removed quite a while ago.

[nathanchance]

As it turns out, that commit is 8c5477e8046c ("x86, boot: Remove multiple copy of static function sanitize_boot_params()") upstream. I am still a little baffled as to why that fixes it but given that it does, we should just submit that to stable and be done with it, as it matches 4.9 and above.

[ihalip]

I am still a little baffled as to why that fixes it

It's the included headers order which has these side effects: "../string.h" redefines the memcpy macro.

[nathanchance]

Patch sent, thanks for the help @ihalip :)

https://lore.kernel.org/stable/[email protected]/

[ihalip]

The patch is now in stable-queue.

[ihalip]

Now in 4.4.193. Resolving.