[PATCH 1/9] objtool: Generic annotation infrastructure

Peter Zijlstra posted 9 patches 1 year, 2 months ago
There is a newer version of this series
[PATCH 1/9] objtool: Generic annotation infrastructure
Posted by Peter Zijlstra 1 year, 2 months ago
Avoid endless .discard.foo sections for each annotation, create a
single .discard.annotate section that takes an annotation type along
with the instruction.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
 include/linux/objtool.h |   18 ++++++++++++++++++
 tools/objtool/check.c   |   45 +++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 63 insertions(+)

--- a/include/linux/objtool.h
+++ b/include/linux/objtool.h
@@ -57,6 +57,13 @@
 	".long 998b\n\t"						\
 	".popsection\n\t"
 
+#define ASM_ANNOTATE(x)						\
+	"911:\n\t"						\
+	".pushsection .discard.annotate,\"M\",@progbits,8\n\t"	\
+	".long 911b - .\n\t"					\
+	".long " __stringify(x) "\n\t"				\
+	".popsection\n\t"
+
 #else /* __ASSEMBLY__ */
 
 /*
@@ -146,6 +153,14 @@
 	.popsection
 .endm
 
+.macro ANNOTATE type:req
+.Lhere_\@:
+	.pushsection .discard.annotate,"M",@progbits,8
+	.long	.Lhere_\@ - .
+	.long	\type
+	.popsection
+.endm
+
 #endif /* __ASSEMBLY__ */
 
 #else /* !CONFIG_OBJTOOL */
@@ -155,6 +170,7 @@
 #define UNWIND_HINT(type, sp_reg, sp_offset, signal) "\n\t"
 #define STACK_FRAME_NON_STANDARD(func)
 #define STACK_FRAME_NON_STANDARD_FP(func)
+#define ASM_ANNOTATE(x)
 #define ANNOTATE_NOENDBR
 #define ASM_REACHABLE
 #else
@@ -167,6 +183,8 @@
 .endm
 .macro REACHABLE
 .endm
+.macro ANNOTATE type:req
+.endm
 #endif
 
 #endif /* CONFIG_OBJTOOL */
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -2373,6 +2373,49 @@ static int read_unwind_hints(struct objt
 	return 0;
 }
 
+static int read_annotate(struct objtool_file *file, void (*func)(int type, struct instruction *insn))
+{
+	struct section *sec;
+	struct instruction *insn;
+	struct reloc *reloc;
+	int type;
+
+	sec = find_section_by_name(file->elf, ".discard.annotate");
+	if (!sec)
+		return 0;
+
+	if (!sec->rsec)
+		return 0;
+
+	if (sec->sh.sh_entsize != 8) {
+		static bool warned = false;
+		if (!warned) {
+			WARN("%s: dodgy linker, sh_entsize != 8", sec->name);
+			warned = true;
+		}
+		sec->sh.sh_entsize = 8;
+	}
+
+	for_each_reloc(sec->rsec, reloc) {
+		type = *(u32 *)(sec->data->d_buf + (reloc_idx(reloc) * sec->sh.sh_entsize) + 4);
+
+		insn = find_insn(file, reloc->sym->sec,
+				 reloc->sym->offset + reloc_addend(reloc));
+		if (!insn) {
+			WARN("bad .discard.annotate entry: %d of type %d", reloc_idx(reloc), type);
+			return -1;
+		}
+
+		func(type, insn);
+	}
+
+	return 0;
+}
+
+static void __annotate_nop(int type, struct instruction *insn)
+{
+}
+
 static int read_noendbr_hints(struct objtool_file *file)
 {
 	struct instruction *insn;
@@ -2670,6 +2713,8 @@ static int decode_sections(struct objtoo
 	if (ret)
 		return ret;
 
+	read_annotate(file, __annotate_nop);
+
 	/*
 	 * Must be before read_unwind_hints() since that needs insn->noendbr.
 	 */
Re: [PATCH 1/9] objtool: Generic annotation infrastructure
Posted by Nathan Chancellor 1 year, 2 months ago
On Fri, Nov 22, 2024 at 01:10:17PM +0100, Peter Zijlstra wrote:
> Avoid endless .discard.foo sections for each annotation, create a
> single .discard.annotate section that takes an annotation type along
> with the instruction.
> 
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
...
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -2373,6 +2373,49 @@ static int read_unwind_hints(struct objt
>  	return 0;
>  }
>  
> +static int read_annotate(struct objtool_file *file, void (*func)(int type, struct instruction *insn))
> +{
> +	struct section *sec;
> +	struct instruction *insn;
> +	struct reloc *reloc;
> +	int type;
> +
> +	sec = find_section_by_name(file->elf, ".discard.annotate");
> +	if (!sec)
> +		return 0;
> +
> +	if (!sec->rsec)
> +		return 0;
> +
> +	if (sec->sh.sh_entsize != 8) {
> +		static bool warned = false;
> +		if (!warned) {
> +			WARN("%s: dodgy linker, sh_entsize != 8", sec->name);

Thanks to Fangrui, this has been resolved in LLVM main:

https://github.com/llvm/llvm-project/commit/d4bed617f4378873d7ddf4b53c041e7b39d1a9ca
https://github.com/ClangBuiltLinux/linux/issues/2057#issuecomment-2495675374

I have built a version of LLVM from main and verified that this warning
does not trigger with that version, while it does with LLVM 19.1.4.

> +			warned = true;
> +		}
> +		sec->sh.sh_entsize = 8;
> +	}
> +
> +	for_each_reloc(sec->rsec, reloc) {
> +		type = *(u32 *)(sec->data->d_buf + (reloc_idx(reloc) * sec->sh.sh_entsize) + 4);
> +
> +		insn = find_insn(file, reloc->sym->sec,
> +				 reloc->sym->offset + reloc_addend(reloc));
> +		if (!insn) {
> +			WARN("bad .discard.annotate entry: %d of type %d", reloc_idx(reloc), type);
> +			return -1;
> +		}
> +
> +		func(type, insn);
> +	}
> +
> +	return 0;
> +}

Cheers,
Nathan
Re: [PATCH 1/9] objtool: Generic annotation infrastructure
Posted by Peter Zijlstra 1 year, 2 months ago
On Sat, Nov 23, 2024 at 08:16:40PM -0700, Nathan Chancellor wrote:
> On Fri, Nov 22, 2024 at 01:10:17PM +0100, Peter Zijlstra wrote:
> > Avoid endless .discard.foo sections for each annotation, create a
> > single .discard.annotate section that takes an annotation type along
> > with the instruction.
> > 
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ...
> > --- a/tools/objtool/check.c
> > +++ b/tools/objtool/check.c
> > @@ -2373,6 +2373,49 @@ static int read_unwind_hints(struct objt
> >  	return 0;
> >  }
> >  
> > +static int read_annotate(struct objtool_file *file, void (*func)(int type, struct instruction *insn))
> > +{
> > +	struct section *sec;
> > +	struct instruction *insn;
> > +	struct reloc *reloc;
> > +	int type;
> > +
> > +	sec = find_section_by_name(file->elf, ".discard.annotate");
> > +	if (!sec)
> > +		return 0;
> > +
> > +	if (!sec->rsec)
> > +		return 0;
> > +
> > +	if (sec->sh.sh_entsize != 8) {
> > +		static bool warned = false;
> > +		if (!warned) {
> > +			WARN("%s: dodgy linker, sh_entsize != 8", sec->name);
> 
> Thanks to Fangrui, this has been resolved in LLVM main:
> 
> https://github.com/llvm/llvm-project/commit/d4bed617f4378873d7ddf4b53c041e7b39d1a9ca
> https://github.com/ClangBuiltLinux/linux/issues/2057#issuecomment-2495675374
> 
> I have built a version of LLVM from main and verified that this warning
> does not trigger with that version, while it does with LLVM 19.1.4.

Excellent, thanks for getting this sorted.

Since there's a fair number of llvm releases between the minimally
supported version to build a kernel with and this fix, I'll leave the
warning as non fatal.

One question; is there any other means of setting entsize aside from
(ab)using SHF_MERGE ? The (GNU) as documetation for .section only
mentions entsize in combination with SHF_MERGE.