Hi Peter, IIRC now the blacklist mechanisms all run on check stage, which after decoding, but the problem of kuser32.S happens in decoding stage. Other than that the assembly symbols in kuser32 is STT_NOTYPE and STACK_FRAME_NON_STANDARD will throw an error for this. OBJECT_FILES_NON_STANDARD works for the single file but as you said after LTO it's invalid. However STACK_FRAME_NON_STANDARD doesn't work for kuser32 case at all. Now my strategy for undecodable instructions is: show an error message and mark insn->ignore = true, but do not stop anything so decoding work can going on. To totally solve this my idea is that applying blacklist before decode. However for this part objtool doesn't have any insn or func info, so we should add a new blacklist just for this case... On 2022/4/29 19:05, Peter Zijlstra wrote: > On Fri, Apr 29, 2022 at 05:43:40PM +0800, Chen Zhongjin wrote: >> From: Raphael Gault <raphael.gault@xxxxxxx> >> >> kuser32 being used for compatibility, it contains a32 instructions >> which are not recognised by objtool when trying to analyse arm64 >> object files. Thus, we add an exception to skip validation on this >> particular file. >> >> Signed-off-by: Raphael Gault <raphael.gault@xxxxxxx> >> Signed-off-by: Julien Thierry <jthierry@xxxxxxxxxx> >> Signed-off-by: Chen Zhongjin <chenzhongjin@xxxxxxxxxx> >> --- >> arch/arm64/kernel/Makefile | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile >> index 986837d7ec82..c4f01bfe79b4 100644 >> --- a/arch/arm64/kernel/Makefile >> +++ b/arch/arm64/kernel/Makefile >> @@ -41,6 +41,9 @@ obj-$(CONFIG_COMPAT) += sys32.o signal32.o \ >> sys_compat.o >> obj-$(CONFIG_COMPAT) += sigreturn32.o >> obj-$(CONFIG_KUSER_HELPERS) += kuser32.o >> + >> +OBJECT_FILES_NON_STANDARD_kuser32.o := y > > File based skipping is depricated in the face of LTO and other link > target based objtool runs. > > Please use function based blacklisting as per the previous patch. > > .
