Re: [uml-devel] [Patch] uml: fix a link error

["Américo Wang" <xiyou.wangcong@gmail.com>]

I am sorry for the delay.

On Sat, Feb 07, 2009 at 12:59:56PM +0100, Heiko Carstens wrote:
>On Wed, 4 Feb 2009 21:54:12 +0100 (CET)
>Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> I verified that Shane's solution:
>> 
>> #define sys_sigprocmask sys_kernel_sigprocmask
>> 
>> works for me, but that's definitely not the cleanest way.
>> 
>> Al Viro also had a suggestion to rework the SYSCALL_DEFINE* macros, but I
>> haven't tried it yet.
>
>
>Patch below should fix it.
>
>
>Subject: [PATCH] syscall define: fix uml compile bug
>
>From: Heiko Carstens <heiko.carstens@de.ibm.com>
>
>With the new system call defines we get this on uml:
>
>arch/um/sys-i386/built-in.o: In function `sys_call_table':
>(.rodata+0x308): undefined reference to `sys_sigprocmask'
>
>Reason for this is that uml passes the preprocessor option
>-Dsigprocmask=kernel_sigprocmask to gcc when compiling the kernel.
>This causes SYSCALL_DEFINE3(sigprocmask, ...) to be expanded to
>SYSCALL_DEFINEx(3, kernel_sigprocmask, ...) and finally to a system call
>named sys_kernel_sigprocmask. However sys_sigprocmask is missing because
>of this.


Hmmm, thanks for analysis this.

I found my mistake, I thought the Makefile invokes the 'strip' command
to do replacement, but it is not, Makefile has a built-in command named
strip. Sorry for this.

Then the problem is fully from preprocessing.


>To avoid macro expansion for the system call name just concatenate the
>name at first define instead of carrying it through severel levels.
>This was pointed out by Al Viro.
>

Yes, indeed!


>Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>


Your patch should fix this problem. But... see below.


> 	}								\
>-	SYSCALL_ALIAS(sys_##name, SyS_##name);				\
>-	static inline long SYSC_##name(__SC_DECL##x(__VA_ARGS__))
>+	SYSCALL_ALIAS(sys##name, SyS##name);				\
>+	static inline long SYSC##name(__SC_DECL##x(__VA_ARGS__))

So your final actual name for a syscall 'foo' will be 'sysfoo'
instead of 'sys_foo', right?

But we have lots of explicit calls to something like sys_foo,
won't your patch break them?


-- 
"Against stupidity, the gods themselves, contend in vain."