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

Américo Wang
2009-02-08T09:07:41Z

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."