2009-01-15 11:41:55

by Cong Wang

[permalink] [raw]
Subject: [Patch] uml: fix a link error


This patch fixes the following link error:

LD .tmp_vmlinux1
arch/um/sys-i386/built-in.o: In function sys_call_table':
(.rodata+0x308): undefined reference to sys_sigprocmask'
collect2: ld returned 1 exit status
KSYM .tmp_kallsyms1.S
nm: '.tmp_vmlinux1': No such file
AS .tmp_kallsyms1.o
LD .tmp_vmlinux2
arch/um/sys-i386/built-in.o: In function sys_call_table':
(.rodata+0x308): undefined reference to sys_sigprocmask'
collect2: ld returned 1 exit status
make[1]: *** [.tmp_vmlinux2] Error 1
make: *** [sub-make] Error 2


Signed-off-by: WANG Cong <[email protected]>
Cc: Jeff Dike <[email protected]>

---
diff --git a/arch/um/sys-i386/sys_call_table.S b/arch/um/sys-i386/sys_call_table.S
index 00e5f52..04147dc 100644
--- a/arch/um/sys-i386/sys_call_table.S
+++ b/arch/um/sys-i386/sys_call_table.S
@@ -6,6 +6,7 @@

#define sys_vm86old sys_ni_syscall
#define sys_vm86 sys_ni_syscall
+#define sys_sigprocmask sigprocmask

#define old_mmap old_mmap_i386







2009-01-16 20:42:46

by Andrew Morton

[permalink] [raw]
Subject: Re: [Patch] uml: fix a link error

On Thu, 15 Jan 2009 19:40:33 +0000
Am__rico Wang <[email protected]> wrote:

>
> This patch fixes the following link error:
>
> LD .tmp_vmlinux1
> arch/um/sys-i386/built-in.o: In function sys_call_table':
> (.rodata+0x308): undefined reference to sys_sigprocmask'
> collect2: ld returned 1 exit status
> KSYM .tmp_kallsyms1.S
> nm: '.tmp_vmlinux1': No such file
> AS .tmp_kallsyms1.o
> LD .tmp_vmlinux2
> arch/um/sys-i386/built-in.o: In function sys_call_table':
> (.rodata+0x308): undefined reference to sys_sigprocmask'
> collect2: ld returned 1 exit status
> make[1]: *** [.tmp_vmlinux2] Error 1
> make: *** [sub-make] Error 2
>
>
> Signed-off-by: WANG Cong <[email protected]>
> Cc: Jeff Dike <[email protected]>
>
> ---
> diff --git a/arch/um/sys-i386/sys_call_table.S b/arch/um/sys-i386/sys_call_table.S
> index 00e5f52..04147dc 100644
> --- a/arch/um/sys-i386/sys_call_table.S
> +++ b/arch/um/sys-i386/sys_call_table.S
> @@ -6,6 +6,7 @@
>
> #define sys_vm86old sys_ni_syscall
> #define sys_vm86 sys_ni_syscall
> +#define sys_sigprocmask sigprocmask
>
> #define old_mmap old_mmap_i386
>

For how long has this problem been present?

Why aren't lots of other people reporting it?

2009-01-16 21:44:26

by Jeff Dike

[permalink] [raw]
Subject: Re: [Patch] uml: fix a link error

On Fri, Jan 16, 2009 at 12:41:58PM -0800, Andrew Morton wrote:
> On Thu, 15 Jan 2009 19:40:33 +0000
> Am__rico Wang <[email protected]> wrote:
> > #define sys_vm86old sys_ni_syscall
> > #define sys_vm86 sys_ni_syscall
> > +#define sys_sigprocmask sigprocmask
> >
> > #define old_mmap old_mmap_i386
> >
>
> For how long has this problem been present?
>
> Why aren't lots of other people reporting it?

There's no problem AFAICT.

This is just bogus.

As you point out, if sigprocmask were missing, people would have
noticed. Also, the proposed definition would pull in the libc
system call wrapper, not the UML system call definition.

Jeff

2009-01-17 20:46:51

by Rob Landley

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

On Friday 16 January 2009 14:41:58 Andrew Morton wrote:
> > diff --git a/arch/um/sys-i386/sys_call_table.S
> > b/arch/um/sys-i386/sys_call_table.S index 00e5f52..04147dc 100644
> > --- a/arch/um/sys-i386/sys_call_table.S
> > +++ b/arch/um/sys-i386/sys_call_table.S
> > @@ -6,6 +6,7 @@
> >
> > #define sys_vm86old sys_ni_syscall
> > #define sys_vm86 sys_ni_syscall
> > +#define sys_sigprocmask sigprocmask
> >
> > #define old_mmap old_mmap_i386
>
> For how long has this problem been present?
>
> Why aren't lots of other people reporting it?

I'm not sure User Mode Linux still has a lot of users regularly testing the
latest and greatest version. (QEMU and KVM kinda took the wind out of its
sails.)

I still find it useful to be able to stick printfs into the code and debug
stuff even when the console isn't working, but I haven't been able to build a
version of 2.6.28 that works for me at all:

cat > mini.conf << EOF
CONFIG_BINFMT_ELF=y
CONFIG_HOSTFS=y
CONFIG_LBD=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_STDERR_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_STATIC_LINK=y
CONFIG_NO_HZ=y
CONFIG_UNEVICTABLE_LRU=y
EOF
make ARCH=um allnoconfig KCONFIG_ALLCONFIG=mini.conf
make ARCH=um -j 3
./linux rw init=/bin/bash rootfstype=hostfs

The result panics (twice) and exits, instead of giving me a shell prompt.
Built and run on stock Ubuntu 8.10. (I posted about it on tuesday, but nobody
replied...)

Rob

2009-01-18 06:23:57

by Daolong Wang

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

I can confirm this link error. And this patch works for me.

On Sat, Jan 17, 2009 at 5:28 PM, Rob Landley <[email protected]> wrote:
> On Friday 16 January 2009 14:41:58 Andrew Morton wrote:
>> > diff --git a/arch/um/sys-i386/sys_call_table.S
>> > b/arch/um/sys-i386/sys_call_table.S index 00e5f52..04147dc 100644
>> > --- a/arch/um/sys-i386/sys_call_table.S
>> > +++ b/arch/um/sys-i386/sys_call_table.S
>> > @@ -6,6 +6,7 @@
>> >
>> > #define sys_vm86old sys_ni_syscall
>> > #define sys_vm86 sys_ni_syscall
>> > +#define sys_sigprocmask sigprocmask
>> >
>> > #define old_mmap old_mmap_i386
>>
>> For how long has this problem been present?
>>
>> Why aren't lots of other people reporting it?
>
> I'm not sure User Mode Linux still has a lot of users regularly testing the
> latest and greatest version. (QEMU and KVM kinda took the wind out of its
> sails.)
>
> I still find it useful to be able to stick printfs into the code and debug
> stuff even when the console isn't working, but I haven't been able to build a
> version of 2.6.28 that works for me at all:
>
> cat > mini.conf << EOF
> CONFIG_BINFMT_ELF=y
> CONFIG_HOSTFS=y
> CONFIG_LBD=y
> CONFIG_BLK_DEV=y
> CONFIG_BLK_DEV_LOOP=y
> CONFIG_STDERR_CONSOLE=y
> CONFIG_UNIX98_PTYS=y
> CONFIG_EXT2_FS=y
> CONFIG_EXT3_FS=y
> CONFIG_STATIC_LINK=y
> CONFIG_NO_HZ=y
> CONFIG_UNEVICTABLE_LRU=y
> EOF
> make ARCH=um allnoconfig KCONFIG_ALLCONFIG=mini.conf
> make ARCH=um -j 3
> ./linux rw init=/bin/bash rootfstype=hostfs
>
> The result panics (twice) and exits, instead of giving me a shell prompt.
> Built and run on stock Ubuntu 8.10. (I posted about it on tuesday, but nobody
> replied...)
>
> Rob
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

2009-01-18 08:33:16

by Cong Wang

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

On Sat, Jan 17, 2009 at 03:28:14AM -0600, Rob Landley wrote:
>On Friday 16 January 2009 14:41:58 Andrew Morton wrote:
>> > diff --git a/arch/um/sys-i386/sys_call_table.S
>> > b/arch/um/sys-i386/sys_call_table.S index 00e5f52..04147dc 100644
>> > --- a/arch/um/sys-i386/sys_call_table.S
>> > +++ b/arch/um/sys-i386/sys_call_table.S
>> > @@ -6,6 +6,7 @@
>> >
>> > #define sys_vm86old sys_ni_syscall
>> > #define sys_vm86 sys_ni_syscall
>> > +#define sys_sigprocmask sigprocmask
>> >
>> > #define old_mmap old_mmap_i386
>>
>> For how long has this problem been present?
>>
>> Why aren't lots of other people reporting it?
>
>I'm not sure User Mode Linux still has a lot of users regularly testing the
>latest and greatest version. (QEMU and KVM kinda took the wind out of its
>sails.)
>
>I still find it useful to be able to stick printfs into the code and debug
>stuff even when the console isn't working, but I haven't been able to build a
>version of 2.6.28 that works for me at all:
>
>cat > mini.conf << EOF
>CONFIG_BINFMT_ELF=y
>CONFIG_HOSTFS=y
>CONFIG_LBD=y
>CONFIG_BLK_DEV=y
>CONFIG_BLK_DEV_LOOP=y
>CONFIG_STDERR_CONSOLE=y
>CONFIG_UNIX98_PTYS=y
>CONFIG_EXT2_FS=y
>CONFIG_EXT3_FS=y
>CONFIG_STATIC_LINK=y
>CONFIG_NO_HZ=y
>CONFIG_UNEVICTABLE_LRU=y
>EOF
>make ARCH=um allnoconfig KCONFIG_ALLCONFIG=mini.conf
>make ARCH=um -j 3
>./linux rw init=/bin/bash rootfstype=hostfs
>
>The result panics (twice) and exits, instead of giving me a shell prompt.
>Built and run on stock Ubuntu 8.10. (I posted about it on tuesday, but nobody
>replied...)

Hi, Rob.

I tried what you said, it works very fine here, on my Fedora 10.
Could you please tell us which kernel your host is using? and the
guest?

Thanks for your feedback.


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

2009-01-18 23:29:46

by Rob Landley

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

On Sunday 18 January 2009 02:32:37 Am?rico Wang wrote:
> >The result panics (twice) and exits, instead of giving me a shell prompt.
> >Built and run on stock Ubuntu 8.10. (I posted about it on tuesday, but
> > nobody replied...)
>
> Hi, Rob.
>
> I tried what you said, it works very fine here, on my Fedora 10.
> Could you please tell us which kernel your host is using?

Ubuntu 8.10 stock kernel, calls itself "2.6.27-9-generic".

> and the guest?

Checking tuesday's bug report, it said:

> Linux version 2.6.28 (landley@driftwood) (gcc version 4.3.2 (Ubuntu
> 4.3.2-1ubuntu11) ) #6 Tue Jan 13 01:54:34 CST 2009

It's the vanilla tarball (albeit extracted from source control according to
the v2.6.28 tag rather than downloaded).

Possibly a gcc 4.3 issue?

Rob

2009-01-19 15:22:11

by Jeff Dike

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

On Sun, Jan 18, 2009 at 02:23:46PM +0800, Daolong Wang wrote:
> I can confirm this link error.

In what environment? I see no problems here.

> And this patch works for me.

Maybe it fixes the link failure. But I really doubt that sigprocmask works.

Jeff

--
Work email - jdike at linux dot intel dot com

2009-01-20 01:46:37

by Daolong Wang

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

On Mon, Jan 19, 2009 at 11:21 PM, Jeff Dike <[email protected]> wrote:
> On Sun, Jan 18, 2009 at 02:23:46PM +0800, Daolong Wang wrote:
>> I can confirm this link error.
>
> In what environment? I see no problems here.
>
Ubuntu 8.04. Gcc is 4.2.4. Sorry I don't have the access to the machine now.
>> And this patch works for me.
>
> Maybe it fixes the link failure. But I really doubt that sigprocmask works.
>
not sure. compile test only!
> Jeff
>
> --
> Work email - jdike at linux dot intel dot com
>

2009-01-20 02:01:26

by Shane Hathaway

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

Daolong Wang wrote:
> On Mon, Jan 19, 2009 at 11:21 PM, Jeff Dike <[email protected]> wrote:
>> On Sun, Jan 18, 2009 at 02:23:46PM +0800, Daolong Wang wrote:
>>> I can confirm this link error.
>> In what environment? I see no problems here.

I can also confirm this link error. The problem occurs when compiling
either 2.6.28.1 or 2.6.27.12; I didn't try anything earlier. The patch
suggested at this beginning of this thread did solve the link problem
and the resulting kernel ran for several hours. However, I think the
patch is still probably incorrect.

I'm going to repost what I said in another message I sent today, this
time with a wider audience:

The problem is that the name "sigprocmask" is getting renamed to
"kernel_sigprocmask" by a compiler directive in arch/um/Makefile, then
that name gets mangled into "sys_kernel_sigprocmask" by the
SYSCALL_DEFINE3(sigprocmask, ...) macro in kernel/signal.c.

So, instead of the patch suggested earlier, I added the following line
to arch/um/sys-i386/sys_call_table.S:

#define sys_sigprocmask sys_kernel_sigprocmask

This made it compile and link correctly. Look at the symbols generated
by the compile of signal.c to see what I mean:

# nm kernel/signal.o | grep sigprocmask
0000008f r __kstrtab_kernel_sigprocmask
00000040 r __ksymtab_kernel_sigprocmask
00001ea6 T kernel_sigprocmask
00002d67 T sys_kernel_sigprocmask
00001faf T sys_rt_sigprocmask

Unfortunately, it's a mystery to me that others haven't run into this
before. My host environment is RHEL 4 inside some kind of chroot.

Shane

2009-01-22 16:13:21

by Cong Wang

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

On Sun, Jan 18, 2009 at 05:29:30PM -0600, Rob Landley wrote:
>On Sunday 18 January 2009 02:32:37 Américo Wang wrote:
>> >The result panics (twice) and exits, instead of giving me a shell prompt.
>> >Built and run on stock Ubuntu 8.10. (I posted about it on tuesday, but
>> > nobody replied...)
>>
>> Hi, Rob.
>>
>> I tried what you said, it works very fine here, on my Fedora 10.
>> Could you please tell us which kernel your host is using?
>
>Ubuntu 8.10 stock kernel, calls itself "2.6.27-9-generic".
>
>> and the guest?
>
>Checking tuesday's bug report, it said:
>
>> Linux version 2.6.28 (landley@driftwood) (gcc version 4.3.2 (Ubuntu
>> 4.3.2-1ubuntu11) ) #6 Tue Jan 13 01:54:34 CST 2009
>
>It's the vanilla tarball (albeit extracted from source control according to
>the v2.6.28 tag rather than downloaded).

I will try 2.6.28.

>
>Possibly a gcc 4.3 issue?

I don't know. :)

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

2009-01-27 09:23:30

by Al Viro

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

On Mon, Jan 19, 2009 at 07:01:07PM -0700, Shane Hathaway wrote:
> The problem is that the name "sigprocmask" is getting renamed to
> "kernel_sigprocmask" by a compiler directive in arch/um/Makefile, then
> that name gets mangled into "sys_kernel_sigprocmask" by the
> SYSCALL_DEFINE3(sigprocmask, ...) macro in kernel/signal.c.
>
> So, instead of the patch suggested earlier, I added the following line
> to arch/um/sys-i386/sys_call_table.S:
>
> #define sys_sigprocmask sys_kernel_sigprocmask

Interesting... Everything else aside, we have difference in e.g.
SYSCALL_DEFINE0 and SYSCALL_DEFINE3 behaviours: SYSCALL_DEFINE0(name)
will *not* do macro expansion in name and SYSCALL_DEFINE3(name, blah, ...)
will.

The reason is that we have name carried through extra layer of macros
in the latter case. Argument is *NOT* a subject to expansion when it
is used with ##; however, passing it to another macro will expand it
just fine.

Regardless of the kludge with -D used by uml, I'd say that we want consistency
here; keeping the original behaviour would also be nice.

How about
#define SYSCALL_DEFINE1(name,...) SYSCALL_DEFINEx(1, _##name, __VA_ARGS__)
etc.
with
#define SYSCALL_DEFINEx(x, name, ...) \
asmlinkage long sys##name(__SC_DECL##x(__VA_ARGS__))
?

That gives consistent behaviour in all cases and avoids the insane side
effects like this one.