Skip to contentSkip to conversation

x86: introduce X86_ assembly names macros to catch unbalanced declaration

RFC In review Cyrill Gorcunov 2 participants 3 messages Nov 23, 2008 x86

lore
Share & tools
lore
#0 lore raw

RFC 1/1 x86: introduce X86_ assembly names macros to catch unbalanced declaration

It's usefull to catch unbalanced or messed declarations of ENTRY and KPROBES. These macros would help a bit (at least I hope so).

For example the following code would compile without problems

	X86_ENTRY(mcount)
		retq
	X86_END(mcount)

But if you forget and mess the following form

	X86_ENTRY(mcount)
		retq
	END(mcount)

	X86_ENTRY(ftrace_caller)

The assembler will issue the following message:
Error: X86_ENTRY/KPROBE unbalanced or missed

Actually the checking is performed at every X86_ macro so maybe it's good idea to put __x86_check_entry_kprobe at the end of .S file to be sure you didn't miss anything.

---

Anyway -- it's just a RFC -- so I hope there will not be much screams of hate :-)

 arch/x86/include/asm/linkage.h |   58 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 58 insertions(+)
arch/x86/include/asm/linkage.h +58 -0
Index: linux-2.6.git/arch/x86/include/asm/linkage.h
===================================================================
@@ -57,5 +57,63 @@
 #define __ALIGN_STR ".align 16,0x90"
 #endif
 
+/*
+ * to check X86_ENTRY/X86_END and
+ * X86_KPROBE_ENTRY/X86_KPROBE_END
+ * unbalanced/messed appearance
+ */
+#define __x86_set_entry   .set _X86_ENTRY_IN, 0
+#define __x86_unset_entry .set _X86_ENTRY_IN, 1
+#define __x86_set_kprobe  .set _X86_KPROBE_IN, 0
+#define __x86_unset_kprobe .set _X86_KPROBE_IN, 1
+
+#define __x86_macro_err .error "X86_ENTRY/KPROBE unbalanced or missed"
+
+#define __x86_check_entry	\
+	.ifdef _X86_ENTRY_IN;	\
+	.ifeq _X86_ENTRY_IN;	\
+	__x86_macro_err;	\
+	.abort;			\
+	.endif;			\
+	.endif
+
+#define __x86_check_kprobe	\
+	.ifdef _X86_KPROBE_IN;	\
+	.ifeq _X86_KPROBE_IN;	\
+	__x86_macro_err;	\
+	.abort;			\
+	.endif;			\
+	.endif
+
+#define __x86_check_entry_kprobe	\
+	__x86_check_entry;		\
+	__x86_check_kprobe
+
+#define X86_ENTRY(name)			\
+	__x86_check_entry_kprobe;	\
+	__x86_set_entry;		\
+	.globl name;			\
+	__ALIGN;			\
+	name:
+
+#define X86_KPROBE_ENTRY(name)		\
+	__x86_check_entry_kprobe;	\
+	__x86_set_kprobe;		\
+	.pushsection .kprobes.text, "ax"; \
+	.globl name;			\
+	__ALIGN;			\
+	name:
+
+#define X86_KPROBE_END(name)		\
+	__x86_unset_kprobe;		\
+	__x86_check_entry_kprobe;	\
+	.size name, .-name;		\
+	.popsection
+
+#define X86_END(name)			\
+	__x86_unset_entry;		\
+	__x86_check_entry_kprobe;	\
+	.size name, .-name
+
 #endif /* _ASM_X86_LINKAGE_H */
 
#1 lore raw
Quoted 11 lines · Cyrill Gorcunov

It's usefull to catch unbalanced or messed declarations of ENTRY and KPROBES. These macros would help a bit (at least I hope so).

For example the following code would compile without problems

	X86_ENTRY(mcount)
		retq
	X86_END(mcount)

But if you forget and mess the following form

Quoted 8 lines
	X86_ENTRY(mcount)
		retq
	END(mcount)

	X86_ENTRY(ftrace_caller)

The assembler will issue the following message:
Error: X86_ENTRY/KPROBE unbalanced or missed

looks good - a very small detail: i'd suggest ENTRY_X86()/END_X86() - because whoever is reading this portion of the code is amply aware of the fact that this is the x86 tree - so the more important information should come first.

Ingo

#2 lore raw

[Ingo Molnar - Sun, Nov 23, 2008 at 05:22:57PM +0100]

| 
| * Cyrill Gorcunov <[email protected]> wrote:
| 
| > It's usefull to catch unbalanced or messed declarations of ENTRY and
| > KPROBES. These macros would help a bit (at least I hope so).
| > 
| > For example the following code would compile without problems
| > 
| > 	X86_ENTRY(mcount)
| > 		retq
| > 	X86_END(mcount)
| > 
| > But if you forget and mess the following form
| > 
| > 	X86_ENTRY(mcount)
| > 		retq
| > 	END(mcount)
| > 
| > 	X86_ENTRY(ftrace_caller)
| > 
| > The assembler will issue the following message:
| > Error: X86_ENTRY/KPROBE unbalanced or missed
| 
| looks good - a very small detail: i'd suggest ENTRY_X86()/END_X86() - 
| because whoever is reading this portion of the code is amply aware of 
| the fact that this is the x86 tree - so the more important information 
| should come first.
| 
| 	Ingo
| 

Will fix shortly :)

- Cyrill -