reorganize <linux/linkage.h>

Commit 54a015104136974262afa4b8ddd943ea70dec8a2 adds some new magic asmlinkage_protect gizmo, but that can only be used from C code, not assembly. Protect relevant bits of <linux/linkage.h> with !__ASSEMBLY__ so this can't leak into assembly source.

Fixes a couple build errors on my boxes,
AS arch/parisc/kernel/pacache.o
In file included from arch/parisc/kernel/pacache.S:40:
include/linux/linkage.h:34: error: syntax error in macro parameter list make[1]: *** [arch/parisc/kernel/pacache.o] Error 1

(__ALIGN gets used in both kernel and assembly context, so make sure it is outside of the ifdeffery.)

---

index b163c5c..e848f74 100644
@@ -3,6 +3,13 @@
 
 #include <asm/linkage.h>
 
+#ifndef __ALIGN
+#define __ALIGN		.align 4,0x90
+#define __ALIGN_STR	".align 4,0x90"
+#endif
+
+#if !defined(__ASSEMBLY__)
+
 #ifdef __cplusplus
 #define CPP_ASMLINKAGE extern "C"
 #else

@@ -34,12 +41,11 @@
 # define asmlinkage_protect(n, ret, args...)	do { } while (0)
 #endif
 
-#ifndef __ALIGN
-#define __ALIGN		.align 4,0x90
-#define __ALIGN_STR	".align 4,0x90"
-#endif
+#define NORET_TYPE    /**/
+#define ATTRIB_NORET  __attribute__((noreturn))
+#define NORET_AND     noreturn,
 
-#ifdef __ASSEMBLY__
+#else
 
 #define ALIGN __ALIGN
 #define ALIGN_STR __ALIGN_STR

@@ -80,10 +86,6 @@
   END(name)
 #endif
 
-#endif
-
-#define NORET_TYPE    /**/
-#define ATTRIB_NORET  __attribute__((noreturn))
-#define NORET_AND     noreturn,
+#endif /*__ASSEMBLY__*/
 
 #endif

Ok, so s390 had a similar issue, and I assumed that they were just usign a broken C pre-processor for asm, but now I'm starting to wonder about it.

Why cannot your pre-processor handle that thing?

It doesn't matter if it is C or assembly, the pre-processor should be the same. That #define isn't used for asm, so it shouldn't _matter_ for asm. What's going on?

I'm starting to suspect that it's the fact that some architectures still have

EXTRA_AFLAGS := -traditional

or equivalent and I'm wondering whether that is really necessary. IIRC x86 got rid of the use of --traditional a long time ago, exactly because it caused problems with any fancier C preprocessor things.

It would probably be much better to try to lose that -traditional from affected architectures, because otherwise issues like this will keep popping up just because the most common architecture doesn't use the limited preprocessor..

Linus

From: Linus Torvalds <[email protected]>
Date: Fri, 11 Apr 2008 07:58:56 -0700 (PDT)

A lot of it is probably simply copy and paste from other ports.

When I removed it from Sparc long ago, the only issue I had was that there were some things using "/**/" concatenation in some sparc assembler CPP macros, and those were easily fixed.