Yocto build compatibility

[sephalon]

See this line in the Yocto recipe on why we need Makefile: rename CFLAGS to CXXFLAGS and add LDFLAGS. sys/targets: allow users to override hardcoded cross-compilers and sys/targets: remove hardcoded CFlags for ARM are based upon a Yocto recipe patch. Note that there might be reasons why we need to force emitting ARMv6 code, but I could not find any hint in the history; so please let me know if we need to approach this issue in a different way.

[a-nogikh]

Regarding the sys/targets: remove hardcoded CFlags for ARM commit. We intentionally do not worry about whether the compiler flags in the Target are always supported because we check for it later. See this part of targets.go:

syzkaller/sys/targets/targets.go

Lines 940 to 953 in d7f584e

	newCFlags := []string{}
	for _, flag := range target.CFlags {
	for {
	if res := flags[flag]; res == nil || *res {
	// The flag is either verified to be supported or must be supported.
	newCFlags = append(newCFlags, flag)
	} else if fallback := fallbackCFlags[flag]; fallback != "" {
	// The flag is not supported, but probably we can replace it by another one.
	flag = fallback
	continue
	}
	break
	}
	}

It wonder why this logic did not work properly in your case. Does it only fire when a specific subset of flags is specified?

[a-nogikh]

Looks good to me

[sephalon]

Regarding the sys/targets: remove hardcoded CFlags for ARM commit. We intentionally do not worry about whether the compiler flags in the Target are always supported because we check for it later. See this part of targets.go:

syzkaller/sys/targets/targets.go

Lines 940 to 953 in d7f584e

	newCFlags := []string{}
	for _, flag := range target.CFlags {
	for {
	if res := flags[flag]; res == nil || *res {
	// The flag is either verified to be supported or must be supported.
	newCFlags = append(newCFlags, flag)
	} else if fallback := fallbackCFlags[flag]; fallback != "" {
	// The flag is not supported, but probably we can replace it by another one.
	flag = fallback
	continue
	}
	break
	}
	}

It wonder why this logic did not work properly in your case. Does it only fire when a specific subset of flags is specified?

@a-nogikh If I understand this logic correctly, only flags listed in optionalCFlags are added to uncommonCFlags and undergo runtime checking via checkFlagSupported(). Therefore, if I add -march=armv6 to optionalCFlags, it is removed by checkFlagSupported() and compilation runs through fine. However, this mechanism obviously will not be able to remove -D__LINUX_ARM_ARCH__=6 as well, which might have unintended side effects. Therefore, is it possible to just remove both -D__LINUX_ARM_ARCH__=6 and -march=armv6 from the hardcoded CFlags?

[a-nogikh]

However, this mechanism obviously will not be able to remove -D__LINUX_ARM_ARCH__=6 as well, which might have unintended side effects. Therefore, is it possible to just remove both -D__LINUX_ARM_ARCH__=6 and -march=armv6 from the hardcoded CFlags?

Actually, I wonder if -D__LINUX_ARM_ARCH__=6 could have had any effect at all. (@dvyukov please correct me if I'm wrong) CFlags only affect the compilation of syz-executor and C reproducers, whereas D__LINUX_ARM_ARCH__ is only used in the non-uapi part of the Linux kernel.

It might affect syz_extract though (since we do compile the kernel using CFlags there), but that's unlikely to affect Yocto (?) unless you want to write custom syzkaller descriptions for your kernel tree.

---

@dvyukov @ramosian-glider Do you know if we have any specific reasons to keep -D__LINUX_ARM_ARCH__=6 and -march=armv6 for building arm32 binaries for arm64 machines?

[ramosian-glider]

I think it should be safe to remove these -D and -march flags already. They date back to 2017, and today armv7 should be more or less the standard.