From: Antoine Martin <antoine@nagafix.co.uk>
To: Blaisorblade <blaisorblade@yahoo.it>
Cc: UML devel <user-mode-linux-devel@lists.sourceforge.net>
Subject: [uml-devel] Re: 2.4.32-bs2
Date: Sun, 11 Dec 2005 19:19:32 +0000 [thread overview]
Message-ID: <1134328772.29209.82.camel@localhost.localdomain> (raw)
In-Reply-To: <200512111747.30441.blaisorblade@yahoo.it>
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
next prev parent reply other threads:[~2005-12-11 19:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-08 2:10 [uml-devel] 2.4.32-bs2 Antoine Martin
2005-12-11 16:47 ` [uml-devel] 2.4.32-bs2 Blaisorblade
2005-12-11 19:19 ` Antoine Martin [this message]
2005-12-11 19:43 ` Blaisorblade
2005-12-12 2:24 ` [uml-devel] [PATCH] " Antoine Martin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1134328772.29209.82.camel@localhost.localdomain \
--to=antoine@nagafix.co.uk \
--cc=blaisorblade@yahoo.it \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox