[uml-devel] 2.4.32-bs2

[uml-devel] 2.4.32-bs2

[Antoine Martin]

All,

Talking about tty logging and fake ide reminded of the current state of
UML on 2.4 kernels:
http://uml.nagafix.co.uk/uml-2.4.32-bs2.patch.bz2
Is Blaisorblade's 2.4.28-bs2 patch tweaked to apply cleanly on 2.4.32.
Plus another tweak to avoid duplicated symbols when linking with newer
libc.a, the patch is based on this one:
http://seclists.org/lists/linux-kernel/2004/Nov/1048.html
But I'm not sure I did it right, so please check it (bottom of this
email is the modified Makefile)

/usr/lib/libc.a: could not read symbols: Bad value
Any idea why that is? It happens when I use:
i686-pc-linux-gnu-3.4.4-vanilla
but not with:
i686-pc-linux-gnu-3.3.6-vanilla
Problem is that the resulting kernel cannot be executed!
$ kernel32-2.4.32-bs2: cannot execute binary file

The other problem with this patch is that I can't get it to compile with
SUBARCH=i386 on amd64.
(even though -bs2 contains a SUBARCH fix - maybe I didn't merge it
properly?)

# make ARCH=um SUBARCH=i386 linux
cd /uml/kernels/src/linux-2.4.32-bs2/include/asm-um && ln
-sf ../asm-i386 arch
cd /uml/kernels/src/linux-2.4.32-bs2/arch/um/include && ln -sf
sysdep-i386 sysdep
cd arch/um && ln -sf os-Linux os
cd /uml/kernels/src/linux-2.4.32-bs2/include/asm-um/ ; \
ln -sf archparam-i386.h archparam.h
cd /uml/kernels/src/linux-2.4.32-bs2/include/asm-um/ ; \
ln -sf system-i386.h system.h
cd /uml/kernels/src/linux-2.4.32-bs2/include/asm-um/ ; \
ln -sf sigcontext-i386.h sigcontext.h
cd /uml/kernels/src/linux-2.4.32-bs2/include/asm-um/ ; \
ln -sf processor-i386.h processor.h
cd /uml/kernels/src/linux-2.4.32-bs2/include/asm-um/ ; \
ln -sf ptrace-i386.h ptrace.h
cd /uml/kernels/src/linux-2.4.32-bs2/include/asm-um/ ; \
ln -sf arch-signal-i386.h arch-signal.h
sed 's/ CONFIG/
UML_CONFIG/' /uml/kernels/src/linux-2.4.32-bs2/include/linux/autoconf.h
> arch/um/include/uml-config.h
make -C arch/um/sys-i386/util mk_sc
make[1]: Entering directory
`/uml/kernels/src/linux-2.4.32-bs2/arch/um/sys-i386/util'
gcc -c mk_sc.c
mk_sc.c: In function `main':
mk_sc.c:21: error: structure has no member named `eip'
mk_sc.c:22: error: structure has no member named `esp'
mk_sc.c:25: error: structure has no member named `ds'
mk_sc.c:26: error: structure has no member named `es'
mk_sc.c:27: error: structure has no member named `ss'
mk_sc.c:30: error: structure has no member named `eax'
mk_sc.c:31: error: structure has no member named `ebx'
mk_sc.c:32: error: structure has no member named `ecx'
mk_sc.c:33: error: structure has no member named `edx'
mk_sc.c:34: error: structure has no member named `edi'
mk_sc.c:35: error: structure has no member named `esi'
mk_sc.c:36: error: structure has no member named `ebp'
mk_sc.c:42: error: structure has no member named `cw'
mk_sc.c:43: error: structure has no member named `sw'
mk_sc.c:44: error: structure has no member named `tag'
mk_sc.c:45: error: structure has no member named `ipoff'
mk_sc.c:46: error: structure has no member named `cssel'
mk_sc.c:47: error: structure has no member named `dataoff'
mk_sc.c:48: error: structure has no member named `datasel'
mk_sc.c:50: error: structure has no member named `_fxsr_env'
make[1]: *** [mk_sc.o] Error 1
make[1]: Leaving directory
`/uml/kernels/src/linux-2.4.32-bs2/arch/um/sys-i386/util'
make: *** [arch/um/sys-i386/util/mk_sc] Error 2

Any ideas?

Antoine

Here is the modified Makefile
$ cat linux-2.4.32-bs2/arch/um/kernel/tt/Makefile
#
# Copyright (C) 2002 - 2003 Jeff Dike (jdike@addtoit.com)
# Licensed under the GPL
#

O_TARGET = tt.o

obj-y = exec_kern.o exec_user.o gdb.o ksyms.o mem.o mem_user.o
process_kern.o \
        syscall_kern.o syscall_user.o time.o tlb.o tracer.o trap_user.o
\
        uaccess.o uaccess_user.o

extra-y := unmap_fin.o
clean-files := unmap_tmp.o

obj-$(CONFIG_PT_PROXY) += gdb_kern.o

subdir-y = sys-$(SUBARCH)
subdir-$(CONFIG_PT_PROXY) += ptproxy

obj-y += $(join $(subdir-y),$(subdir-y:%=/%.o))

export-objs = ksyms.o

USER_OBJS = $(filter %_user.o,$(obj-y)) gdb.o time.o tracer.o

UNMAP_CFLAGS := $(patsubst -pg -DPROFILING,,$(USER_CFLAGS))
UNMAP_CFLAGS := $(patsubst -fprofile-arcs -ftest-coverage,,
$(UNMAP_CFLAGS))

include $(TOPDIR)/Rules.make

$(USER_OBJS) : %.o: %.c
        $(CC) $(CFLAGS_$@) $(USER_CFLAGS) -c -o $@ $<

$(O_TARGET) : unmap_fin.o

unmap.o: unmap.c
        $(CC) $(UNMAP_CFLAGS) -c -o $@ $<

unmap_fin.o : unmap.o
        ld -r -o unmap_tmp.o unmap.o -lc -L/usr/lib
        objcopy unmap_tmp.o unmap_fin.o -G switcheroo

clean :



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: 2.4.32-bs2

[Blaisorblade]

On Thursday 08 December 2005 03:10, Antoine Martin wrote:
> All,
>
> Talking about tty logging and fake ide reminded of the current state of
> UML on 2.4 kernels:
> http://uml.nagafix.co.uk/uml-2.4.32-bs2.patch.bz2
> Is Blaisorblade's 2.4.28-bs2 patch tweaked to apply cleanly on 2.4.32.

There should be (I think) just offsets, not even fuzzes, so there should be no 
problem.

> Plus another tweak to avoid duplicated symbols when linking with newer
> libc.a, the patch is based on this one:
> http://seclists.org/lists/linux-kernel/2004/Nov/1048.html
> But I'm not sure I did it right, so please check it (bottom of this
> email is the modified Makefile)

Seems correct for what I can see. Ah, no, there's a 2.4 / 2.6 conversion 
problem, see below.

> /usr/lib/libc.a: could not read symbols: Bad value

I'd like to see the exact cmd line producing this. Possibly seeing also gcc -v 
output with that cmd line would help.

(After seeing if there's anything strange with the file itself, but I think 
you can compile on the same box some 

> Any idea why that is? It happens when I use:
> i686-pc-linux-gnu-3.4.4-vanilla
> but not with:
> i686-pc-linux-gnu-3.3.6-vanilla 

The first thing I'd do there (since this is the fscking 2.4, not the shining 
2.6) is doing a make mrproper ARCH=um between the two compiles... 2.4 kbuild 
was so erratic that even recently I was bitten from it, too... I started 
writing a patch (missing export_symbol, I thought) to discover that a) the 
code seemed right and b) the code _was_ right.

Afterwards I'd be curious if some strange Gentoo thing is mixing 
runtime .so/.a libraries of the two compilers (I've had this happening for 
c++, and programs crashing after linking with both gcc 3.3 and gcc 3.4 stdc++ 
libraries - fix_libtool_files.sh on Gentoo was my friend in the end). Note 
that you need to be especially lucky to trigger this - of the whole KDE 
3.4.3, most was linked this way, but only "juk" suffered.

No idea, I'll look at it a bit (maybe), but it's very strange. Note that I 
recall compiling that with GCC 3.4.x (.3?) - I wanted to support 3.4 when 
releasing -bs2.

> Problem is that the resulting kernel cannot be executed!
> $ kernel32-2.4.32-bs2: cannot execute binary file

file vmlinux-* and/or dmesg|tail would maybe help on what was going on.

> The other problem with this patch is that I can't get it to compile with
> SUBARCH=i386 on amd64.
> (even though -bs2 contains a SUBARCH fix - maybe I didn't merge it
> properly?)

Hmm, I never compiled 2.4 kernels on x86_64 machines. Probably I backported 
just an earlier attempt - in fact I thought I'd done it on 2.6, but until I 
started testing it, it didn't work.

For that, I'm sorry but you need a chroot - just too much work and I've not 
the time to work on this.

> Any ideas?

> Antoine

> Here is the modified Makefile

Next time send a patch (even cut 'n' paste, but a patch).

> $ cat linux-2.4.32-bs2/arch/um/kernel/tt/Makefile
> #
> # Copyright (C) 2002 - 2003 Jeff Dike (jdike@addtoit.com)
> # Licensed under the GPL
> #
>
> O_TARGET = tt.o
>
> obj-y = exec_kern.o exec_user.o gdb.o ksyms.o mem.o mem_user.o
> process_kern.o \
>         syscall_kern.o syscall_user.o time.o tlb.o tracer.o trap_user.o
> \
>         uaccess.o uaccess_user.o

> extra-y := unmap_fin.o
> clean-files := unmap_tmp.o

Get rid of these lines, they didn't exist. Extra-y must be expressed, but ok, 
it's already coded (see below). (clean-files is for make clean).

> obj-$(CONFIG_PT_PROXY) += gdb_kern.o
>
> subdir-y = sys-$(SUBARCH)
> subdir-$(CONFIG_PT_PROXY) += ptproxy
>
> obj-y += $(join $(subdir-y),$(subdir-y:%=/%.o))
>
> export-objs = ksyms.o
>
> USER_OBJS = $(filter %_user.o,$(obj-y)) gdb.o time.o tracer.o
>
> UNMAP_CFLAGS := $(patsubst -pg -DPROFILING,,$(USER_CFLAGS))
> UNMAP_CFLAGS := $(patsubst -fprofile-arcs -ftest-coverage,,
> $(UNMAP_CFLAGS))
>
> include $(TOPDIR)/Rules.make
>
> $(USER_OBJS) : %.o: %.c
>         $(CC) $(CFLAGS_$@) $(USER_CFLAGS) -c -o $@ $<

USER_CFLAGS and CFLAGS_$@ are in the wrong order, the latter must be able to 
override the former. Not that it should be a problem here... (and it's even 
in the original, so don't worry).

> $(O_TARGET) : unmap_fin.o

The above is the (approximate) equivalent of extra-y setting.

> unmap.o: unmap.c
>         $(CC) $(UNMAP_CFLAGS) -c -o $@ $<
>
> unmap_fin.o : unmap.o
>         ld -r -o unmap_tmp.o unmap.o -lc -L/usr/lib
>         objcopy unmap_tmp.o unmap_fin.o -G switcheroo

Yep, these are correct.

> clean :

-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: 2.4.32-bs2

[Antoine Martin]

On Sun, 2005-12-11 at 17:47 +0100, Blaisorblade wrote:
> On Thursday 08 December 2005 03:10, Antoine Martin wrote:
> > All,
> >
> > Talking about tty logging and fake ide reminded of the current state of
> > UML on 2.4 kernels:
> > http://uml.nagafix.co.uk/uml-2.4.32-bs2.patch.bz2
> > Is Blaisorblade's 2.4.28-bs2 patch tweaked to apply cleanly on 2.4.32.
> 
> There should be (I think) just offsets, not even fuzzes, so there should be no 
> problem.
There were some offsets and one empty reject, so no real problem.

> > Plus another tweak to avoid duplicated symbols when linking with newer
> > libc.a, the patch is based on this one:
> > http://seclists.org/lists/linux-kernel/2004/Nov/1048.html
> > But I'm not sure I did it right, so please check it (bottom of this
> > email is the modified Makefile)
> 
> Seems correct for what I can see. Ah, no, there's a 2.4 / 2.6 conversion 
> problem, see below.
> 
> > /usr/lib/libc.a: could not read symbols: Bad value
> 
> I'd like to see the exact cmd line producing this. Possibly seeing also gcc -v 
> output with that cmd line would help.
# gcc -v -Wl,-T,arch/um/link.ld -static -Wl,--wrap,malloc
-Wl,--wrap,free -Wl,--wrap,calloc         -o linux arch/um/main.o
vmlinux.o -L/usr/lib -lutil
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/specs
Configured with: /var/tmp/portage/gcc-3.4.4-r1/work/gcc-3.4.4/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.4.4
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.4
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.4/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.4/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/g
++-v3 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu
--disable-altivec --enable-nls --without-included-gettext
--with-system-zlib --disable-checking --disable-werror
--disable-libunwind-exceptions --disable-multilib --disable-libmudflap
--disable-libgcj --enable-languages=c,c++ --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 3.4.4 (Gentoo Hardened 3.4.4-r1, HTB-3.4.4-1.00,
ssp-3.4.4-1.0, pie-8.7.8)
 /usr/libexec/gcc/i686-pc-linux-gnu/3.4.4/collect2 -m elf_i386 -static
-z relro -z now -o
linux /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../crt1.o /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../crti.o /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/crtbeginT.o -L/usr/lib -L/usr/lib/gcc/i686-pc-linux-gnu/3.4.4 -L/usr/lib/gcc/i686-pc-linux-gnu/3.4.4 -L/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../i686-pc-linux-gnu/lib -L/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/../../.. -T arch/um/link.ld --wrap malloc --wrap free --wrap calloc arch/um/main.o vmlinux.o -lutil --start-group -lgcc -lgcc_eh -lc --end-group /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/crtend.o /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../crtn.o
/usr/lib/libc.a: could not read symbols: Bad value
collect2: ld returned 1 exit status

> (After seeing if there's anything strange with the file itself, but I think 
> you can compile on the same box some 
> 
> > Any idea why that is? It happens when I use:
> > i686-pc-linux-gnu-3.4.4-vanilla
> > but not with:
> > i686-pc-linux-gnu-3.3.6-vanilla 
Trying again today with 3.3.6, I get a new warning (bcmp) and the same
error. I have no idea what I've done different!

gcc -Wl,-T,arch/um/link.ld -static -Wl,--wrap,malloc -Wl,--wrap,free
-Wl,--wrap,calloc \
        -o linux arch/um/main.o vmlinux.o -L/usr/lib -lutil
/usr/lib/libc.a(memcmp.o): In function `bcmp':
../sysdeps/i386/i686/memcmp.S:(.text+0x0): multiple definition of
`memcmp'
vmlinux.o:/usr/src/linux-2.4.32-bs2/lib/string.c:452: first defined here
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/../../../../i686-pc-linux-gnu/bin/ld: Warning: size of symbol `memcmp' changed from 53 in vmlinux.o to 128 in /usr/lib/libc.a(memcmp.o)
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libgcc.a: could not read
symbols: Bad value
collect2: ld returned 1 exit status
make: *** [linux] Error 1


> 
> The first thing I'd do there (since this is the fscking 2.4, not the shining 
> 2.6) is doing a make mrproper ARCH=um between the two compiles... 2.4 kbuild 
> was so erratic that even recently I was bitten from it, too... I started 
> writing a patch (missing export_symbol, I thought) to discover that a) the 
> code seemed right and b) the code _was_ right.
(Good way to waste some time ;) I have used mrproper.

> Afterwards I'd be curious if some strange Gentoo thing is mixing 
> runtime .so/.a libraries of the two compilers (I've had this happening for 
> c++, and programs crashing after linking with both gcc 3.3 and gcc 3.4 stdc++ 
> libraries - fix_libtool_files.sh on Gentoo was my friend in the end). Note 
> that you need to be especially lucky to trigger this - of the whole KDE 
> 3.4.3, most was linked this way, but only "juk" suffered.
fix_libtool_files.sh did fix some libs when I upgraded to 3.4 - but did
not help in this case.

> No idea, I'll look at it a bit (maybe), but it's very strange. Note that I 
> recall compiling that with GCC 3.4.x (.3?) - I wanted to support 3.4 when 
> releasing -bs2.
> 
> > Problem is that the resulting kernel cannot be executed!
> > $ kernel32-2.4.32-bs2: cannot execute binary file
> 
> file vmlinux-* and/or dmesg|tail would maybe help on what was going on.
/home/viper/kernel32-2.4.32-bs2: ELF 32-bit LSB relocatable, Intel
80386, version 1 (SYSV), not stripped

(nothing in dmesg)
> 
> > The other problem with this patch is that I can't get it to compile with
> > SUBARCH=i386 on amd64.
> > (even though -bs2 contains a SUBARCH fix - maybe I didn't merge it
> > properly?)
> 
> Hmm, I never compiled 2.4 kernels on x86_64 machines. Probably I backported 
> just an earlier attempt - in fact I thought I'd done it on 2.6, but until I 
> started testing it, it didn't work.
Not to worry, I just thought it was meant to work.
How would I go about building a 32-bit pcap enabled kernel in the
chroot? Do I copy the pcap.a from outside the chroot?

> For that, I'm sorry but you need a chroot - just too much work and I've not 
> the time to work on this.
2.4 is not worth spending too much time on anyway.

> > Here is the modified Makefile
> 
> Next time send a patch (even cut 'n' paste, but a patch).
I almost did, but the patch was twice as long... will do next time.

> > $ cat linux-2.4.32-bs2/arch/um/kernel/tt/Makefile
> > #
> > # Copyright (C) 2002 - 2003 Jeff Dike (jdike@addtoit.com)
> > # Licensed under the GPL
> > #
> >
> > O_TARGET = tt.o
> >
> > obj-y = exec_kern.o exec_user.o gdb.o ksyms.o mem.o mem_user.o
> > process_kern.o \
> >         syscall_kern.o syscall_user.o time.o tlb.o tracer.o trap_user.o
> > \
> >         uaccess.o uaccess_user.o
> 
> > extra-y := unmap_fin.o
> > clean-files := unmap_tmp.o
> 
> Get rid of these lines, they didn't exist. Extra-y must be expressed, but ok, 
> it's already coded (see below). (clean-files is for make clean).
ok

> > obj-$(CONFIG_PT_PROXY) += gdb_kern.o
> >
> > subdir-y = sys-$(SUBARCH)
> > subdir-$(CONFIG_PT_PROXY) += ptproxy
> >
> > obj-y += $(join $(subdir-y),$(subdir-y:%=/%.o))
> >
> > export-objs = ksyms.o
> >
> > USER_OBJS = $(filter %_user.o,$(obj-y)) gdb.o time.o tracer.o
> >
> > UNMAP_CFLAGS := $(patsubst -pg -DPROFILING,,$(USER_CFLAGS))
> > UNMAP_CFLAGS := $(patsubst -fprofile-arcs -ftest-coverage,,
> > $(UNMAP_CFLAGS))
> >
> > include $(TOPDIR)/Rules.make
> >
> > $(USER_OBJS) : %.o: %.c
> >         $(CC) $(CFLAGS_$@) $(USER_CFLAGS) -c -o $@ $<
> 
> USER_CFLAGS and CFLAGS_$@ are in the wrong order, the latter must be able to 
> override the former. Not that it should be a problem here... (and it's even 
> in the original, so don't worry).
I've swapped them.

> > $(O_TARGET) : unmap_fin.o
> 
> The above is the (approximate) equivalent of extra-y setting.
> 
> > unmap.o: unmap.c
> >         $(CC) $(UNMAP_CFLAGS) -c -o $@ $<
> >
> > unmap_fin.o : unmap.o
> >         ld -r -o unmap_tmp.o unmap.o -lc -L/usr/lib
> >         objcopy unmap_tmp.o unmap_fin.o -G switcheroo
I'll send a patch when the whole thing works.

Antoine



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: 2.4.32-bs2

[Blaisorblade]

On Sunday 11 December 2005 20:19, Antoine Martin wrote:
> On Sun, 2005-12-11 at 17:47 +0100, Blaisorblade wrote:
> > On Thursday 08 December 2005 03:10, Antoine Martin wrote:
> > > All,
> > >
> > > Talking about tty logging and fake ide reminded of the current state of
> > > UML on 2.4 kernels:
> > > http://uml.nagafix.co.uk/uml-2.4.32-bs2.patch.bz2
> > > Is Blaisorblade's 2.4.28-bs2 patch tweaked to apply cleanly on 2.4.32.
> >
> > There should be (I think) just offsets, not even fuzzes, so there should
> > be no problem.

> > > /usr/lib/libc.a: could not read symbols: Bad value

> > I'd like to see the exact cmd line producing this. Possibly seeing also
> > gcc -v output with that cmd line would help.


> collect2: ld returned 1 exit status

> > (After seeing if there's anything strange with the file itself, but I
> > think you can compile on the same box some

> > > Any idea why that is? It happens when I use:
> > > i686-pc-linux-gnu-3.4.4-vanilla
> > > but not with:
> > > i686-pc-linux-gnu-3.3.6-vanilla

> Trying again today with 3.3.6, I get a new warning (bcmp) and the same
> error.

The warning is about two memcmp() definitions, of which one is from libc and 
one from UML. And memcmp() is called in bcmp(), triggering the error.

> I have no idea what I've done different! 

Ok, now we have that the difference between 3.3 and 3.4 could be in collect2, 
the ld wrapper, which was discarding the useful message. I don't think gcc 
3.4 could do anything differently. (I've not looked at linux-2.4.32 sources, 
though, I'm 

> gcc -Wl,-T,arch/um/link.ld -static -Wl,--wrap,malloc -Wl,--wrap,free
> -Wl,--wrap,calloc \
>         -o linux arch/um/main.o vmlinux.o -L/usr/lib -lutil
> /usr/lib/libc.a(memcmp.o): In function `bcmp':
> ../sysdeps/i386/i686/memcmp.S:(.text+0x0): multiple definition of
> `memcmp'

Notice the line below:

> vmlinux.o:/usr/src/linux-2.4.32-bs2/lib/string.c:452: first defined here

I.e. memcmp is multiply defined.

> /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/../../../../i686-pc-linux-gnu/bin/
>ld: Warning: size of symbol `memcmp' changed from 53 in vmlinux.o to 128 in
> /usr/lib/libc.a(memcmp.o)

This particular warning (size of function changed) may depend on gcc 3.3 
creating 53-bytes of code and gcc used for glibc using 128 ones (doh!). 
However it's a stupid way to say again "duplicate symbol".

Ok, this makes *much* sense to me, and we had that in 2.6. I'm not sure why it 
started appearing here, I think it started existing either for some kernel 
cleanup or for what else... (maybe the kernel cleanup got backported in 
2.4.32).

I think in that case I #ifdefed just the function definition (for memcmp, not 
for bcmp!) in lib/string.c, while keeping the EXPORT_SYMBOL() line (wherever 
it is).

> fix_libtool_files.sh did fix some libs when I upgraded to 3.4 - but did
> not help in this case.

ok, no more worry, the current 3.3 error message *is* informative.


> > Hmm, I never compiled 2.4 kernels on x86_64 machines. Probably I
> > backported just an earlier attempt - in fact I thought I'd done it on
> > 2.6, but until I started testing it, it didn't work.
>
> Not to worry, I just thought it was meant to work.

> How would I go about building a 32-bit pcap enabled kernel in the
> chroot? Do I copy the pcap.a from outside the chroot?

No, pcap.a is a static library so you don't need that. The problem is that you 
need a matching glibc inside the chroot and outside for the libraries which 
are dlopen()ed by glibc, i.e. the whole libnss + helpers called 
by /etc/nsswitch.conf for instance. On my system the linker spits out a 
warning to say that ("You must have the same glibc used for compiling, even 
if you're linking statically").

Hope that glibc people have not been so strict.

> I almost did, but the patch was twice as long... will do next time.

Sometimes this can happen, the problem is that probably a patch (even for this 
file only) is (normally) more readable.

[... I read your answers on the patch ...]

> I'll send a patch when the whole thing works.

The patch is for review, and please don't send any whole patch on the ML - 
limit to the interesting hunks, with reference URLs if needed (let's avoid 
spamming people).
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

		
___________________________________ 
Yahoo! Messenger: chiamate gratuite in tutto il mondo 
http://it.messenger.yahoo.com



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] [PATCH] Re: 2.4.32-bs2

[Antoine Martin]

[-- Attachment #1: Type: text/plain, Size: 1988 bytes --]

> > I have no idea what I've done different! 
I was using mrproper, but I've scripted the whole thing to test all the
combinations from scratch again (with a brand new tree each time - not
just mrproper) and the error only occurs when using the hardened gcc,
and I'm not too bothered about that (it's easy enough to switch, except
in SELinux enforcing mode - but that's another matter...)

So I guess that the patch is good enough as it is.
It is available here:
http://uml.nagafix.co.uk/uml-2.4.32-bs2.patch.bz2
it cumulates:
* 2.4.28-bs2
* offsets for 2.4.32 and removed the whitespace no-change in
drivers/char/tty_io.c.rej
* tiny patch (attached) for tt/Makefile to cope with duplicate symbols
in newer glibc
(done properly this time)
* mconsole-exec patch backported to 2.4:
http://uml.nagafix.co.uk/mconsole-exec.patch-2.4.bz2
(unlike in 2.6 there is no config option for it)

> > How would I go about building a 32-bit pcap enabled kernel in the
> > chroot? Do I copy the pcap.a from outside the chroot?
> 
> No, pcap.a is a static library so you don't need that. The problem is that you 
> need a matching glibc inside the chroot and outside for the libraries which 
> are dlopen()ed by glibc, i.e. the whole libnss + helpers called 
> by /etc/nsswitch.conf for instance. On my system the linker spits out a 
> warning to say that ("You must have the same glibc used for compiling, even 
> if you're linking statically").
Same here. I wish it could tell me which ones so I could place them in
the chroot without guessing or tracing it (we have discussed this a
while back)

So in this case, on a multilib amd64 system, I should be able to build a
chroot using a bind mount to preserve /lib32 and /usr/lib32 to guarantee
that the libs are exactly the same? (and add a 32bit bash, gcc, make...)

> > I'll send a patch when the whole thing works.
> 
> The patch is for review, and please don't send any whole patch on the ML - 
Sure, I meant just the diffs with 2.4.28-bs2!

Antoine

[-- Attachment #2: 2.4.32-bs2-tt-makefile.patch --]
[-- Type: text/x-patch, Size: 617 bytes --]

--- linux-2.4.32/arch/um/kernel/tt/Makefile     2005-12-13 03:29:03.000000000 +0000
+++ linux-2.4.32-bs2/arch/um/kernel/tt/Makefile 2005-12-13 03:27:52.000000000 +0000
@@ -26,7 +26,7 @@
 include $(TOPDIR)/Rules.make

 $(USER_OBJS) : %.o: %.c
-       $(CC) $(CFLAGS_$@) $(USER_CFLAGS) -c -o $@ $<
+       $(CC) $(USER_CFLAGS) $(CFLAGS_$@) -c -o $@ $<

 $(O_TARGET) : unmap_fin.o

@@ -34,6 +34,7 @@
        $(CC) $(UNMAP_CFLAGS) -c -o $@ $<

 unmap_fin.o : unmap.o
-       ld -r -o $@ $< -lc -L/usr/lib
+       ld -r -o unmap_tmp.o unmap.o -lc -L/usr/lib
+       objcopy unmap_tmp.o unmap_fin.o -G switcheroo

 clean :