Re: [PATCH v13.1 04/23] x86/stacktool: Compile-time stack metadata validation

[Chris J Arges <chris.j.arges@canonical.com>]

<snip>
> +
> +$(STACKTOOL_IN): FORCE
> +	@$(MAKE) $(build)=stacktool
> +
> +$(STACKTOOL): $(STACKTOOL_IN)
> +	@(test -d ../../kernel -a -d ../../tools -a -d ../stacktool && (( \
> +	diff -I'^#include' arch/x86/insn/insn.c ../../arch/x86/lib/insn.c >/dev/null && \
> +	diff -I'^#include' arch/x86/insn/inat.c ../../arch/x86/lib/inat.c >/dev/null && \
> +	diff arch/x86/insn/x86-opcode-map.txt ../../arch/x86/lib/x86-opcode-map.txt >/dev/null && \
> +	diff arch/x86/insn/gen-insn-attr-x86.awk ../../arch/x86/tools/gen-insn-attr-x86.awk >/dev/null && \
> +	diff -I'^#include' arch/x86/insn/insn.h ../../arch/x86/include/asm/insn.h >/dev/null && \
> +	diff -I'^#include' arch/x86/insn/inat.h ../../arch/x86/include/asm/inat.h >/dev/null && \
> +	diff -I'^#include' arch/x86/insn/inat_types.h ../../arch/x86/include/asm/inat_types.h >/dev/null) \
> +	|| echo "Warning: stacktool: x86 instruction decoder differs from kernel" >&2 )) || true
> +	$(QUIET_LINK)$(CC) $(STACKTOOL_IN) $(LDFLAGS) -o $@
> +
> +clean:
> +	$(call QUIET_CLEAN, stacktool) $(RM) $(STACKTOOL)
> +	$(Q)find $(OUTPUT) -name '*.o' -delete -o -name '\.*.cmd' -delete -o -name '\.*.d' -delete
> +	$(Q)$(RM) $(OUTPUT)arch/x86/insn/inat-tables.c
> +
> +FORCE:
> +
> +.PHONY: clean FORCE

Josh,

I'm getting the following error when the above makefile is called:
Warning: stacktool: x86 instruction decoder differs from kernel

This was seen with your patches rebased on v4.3-rc2.

It is failing on this diff:
diff arch/x86/insn/x86-opcode-map.txt ../../arch/x86/lib/x86-opcode-map.txt

And the output is as follows:
902,904d890
< 3: xrstors
< 4: xsavec
< 5: xsaves
949,950c935,936
< 6: XSAVEOPT | clwb (66) | mfence (11B)
< 7: clflush | clflushopt (66) | sfence (11B) | pcommit (66),(11B)
---
> 6: XSAVEOPT | mfence (11B)
> 7: clflush | sfence (11B)

Why do these files essentially need to be duplicated? Would it be possible to
point Make at the files that are already in ../../arch/x86/*?

--chris j arges