Re: [uml-devel] [Bug 49277] Compile of usermode-sources-2.6.x fails

[Blaisorblade <blaisorblade@yahoo.it>]

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

On Tuesday 07 June 2005 21:47, Nix wrote:
> On Tue, 7 Jun 2005, blaisorblade@yahoo.it suggested tentatively:
> > On Tuesday 07 June 2005 18:21, Nix wrote:
> >> OK, so it's a -static TT build that's failing?
> >
> > Exactly.
>
> Built, with a randomly selected .config (that is, a .config I use for
> other things, not a .config with the values set at random!)
Hmm, broken-out in the archives works perfectly (with patch-scripts). Go until 
uml-link-tt-mode-against-nptl.patch and retry, and possibly even with the 
previous one... please.

> Not quite built without problems. Can you guess the cause of this?

> Guess where the static libutil.a is. That's right, /usr/lib. Are
> we searching it in that linker script? No :(
Ok, wait that I emerge that newer version and build starts failing here too 
and you'll get that fixed. A proper patch (ok for whatever SUBARCH you need) 
would be ok, either... Ok, it's doable because I must now link in 
arch/um/sys-SUBARCH/unmap_fin.o (it's done in -bs6 too), by passing 
-DSUBARCH=$(SUBARCH). You can pass a define for the path, too.

>
> With that applied, it builds...
>
> ... and segfaults almost at once on invocation:
>
> execve("./vmlinux", ["./vmlinux"], [/* 49 vars */]) = 0
> uname({sys="Linux", node="hades", ...}) = 0
> brk(0)                                  = 0xa0343000
> brk(0xa0343834)                         = 0xa0343834
> set_thread_area({entry_number:-1 -> 6, base_addr:0xa034381c, limit:1048575,
> seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
> seg_not_present:0, useable:1}) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0)

Hmm, gdb would be more helpful... I was getting a SIGBUS somewhere on x86_64 
(with a native binary) here, and maybe it could be the same thing (no, it 
can't, your error is different, so I'm talking to myself):

(gdb) c
Continuing.
Checking for /proc/mm...found
Checking for the skas3 patch in the host...not found
Checking PROT_EXEC mmap in /tmp...OK

Program received signal SIGBUS, Bus error.
0x00000000601fee40 in memset ()
(gdb) where
#0  0x00000000601fee40 in memset ()
#1  0x0000000060006f4e in init_bootmem_core ()
#2  0x0000000060011259 in setup_physmem ()
#3  0x000000006001870d in linux_main ()
#4  0x000000006000fe91 in main ()

From the value in memset registers and from the code, it's this call in 
init_bootmem_core():
        memset(bdata->node_bootmem_map, 0xff, mapsize);

And here is the memory map... whoops! The code is trying to read from 
60c00000, which is mapped... but from an absurd address! And from a different 
file from all the rest!

$ cat /proc/904/maps
60000000-60001000 rwxp 00000000 fe:02 
1173995                            /home/paolo/Admin/kernel/6/clean-linux-2.6.11/vmlinux
60001000-60238000 rwxs 00000000 00:0e 
1383099                            /tmp/vm_file-VOy5x5 (deleted)
60238000-60325000 rwxs 00000000 00:0e 
1383100                            /tmp/vm_file-16FWOn (deleted)
60325000-6045b000 rwxs 00000000 00:0e 
1383101                            /tmp/vm_file-8DBi6F (deleted)
6045b000-6047c000 rwxp 6045b000 00:00 0                                  
[heap]
60c00000-a2000000 rwxs ffffffffc0c00000 00:0e 
1383102                    /tmp/vm_file-JmW1nY (deleted)
2aaaaaaab000-2aaaaaaac000 rwxp 2aaaaaaab000 00:00 0
7fffffae1000-7fffffaf6000 rwxp 7fffffae1000 00:00 0                      
[stack]
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0                  
[vdso]

> Looks like a thread initialization problem to *me*. And there be very
> serious and nasty snarling dragons with sharp pointy carborundum teeth
Hmm, can you pass those along to kill the Computer against which I'm playing 
at Warcraft III?
> :(
This kind of problems is normally caused from wrong alignments in the linker 
script.

> (this box, btw, is an AMD Athlon 4: it *does* have CMOV support. Not
> that that could plausibly be the problem here.)

> Whoops!

> I guess not many people have tried to build -bs6, then: I doubt that would
> work terribly well in skas mode, either ;)
Guess it wouldn't build stop.
> > Seems like I'll have to resort to something bad... which is attached,
> > i.e. black magic (using -U from time to time).
>
> Black magic during debugging makes me nervous, so...

> > Alternatively, use patch1.bz2 and patch2.bz2, which have normal context
> > (the final patch has been generated by merging them).
>
> ... I used these, which applied fine.
Btw, I forgot that broken-out is in perfect state and would help more for 
debug...


> `Seasonal allergic rhinitis',
Exactly.
> i.e., plants trying to have sex with my 
> nose over my violent protests.

> Well, it's done that in the south-east of England, too, but I don't have
> to like it, and it's `exceptional' (i.e. `has happened almost every year
> for the last decade' :( )
Global warming, isn't it? However don't worry, the Gulf Current is going to 
stop so you'll get refreshed of -10 degrees...
-- 
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

[-- Attachment #2: uml-pcap-on-64bit-host.patch --]
[-- Type: text/x-diff, Size: 1789 bytes --]



Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---

 clean-linux-2.6.11-paolo/arch/um/drivers/Makefile       |    4 ++--
 clean-linux-2.6.11-paolo/arch/um/scripts/Makefile.unmap |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff -puN arch/um/drivers/Makefile~uml-pcap-on-64bit-host arch/um/drivers/Makefile
--- clean-linux-2.6.11/arch/um/drivers/Makefile~uml-pcap-on-64bit-host	2005-06-08 02:09:55.000000000 +0200
+++ clean-linux-2.6.11-paolo/arch/um/drivers/Makefile	2005-06-08 02:09:55.000000000 +0200
@@ -17,10 +17,10 @@ ubd-objs := ubd_kern.o ubd_user.o
 port-objs := port_kern.o port_user.o
 harddog-objs := harddog_kern.o harddog_user.o
 
-LDFLAGS_pcap.o := -r -lpcap -L/usr/lib
+LDFLAGS_pcap.o := -r $(shell $(CC) $(CFLAGS) -print-file-name=libpcap.a)
 
 $(obj)/pcap.o: $(obj)/pcap_kern.o $(obj)/pcap_user.o
-	$(LD) -r -dp -o $@ $^ $(LDFLAGS_pcap.o)
+	$(LD) -r -dp -o $@ $^ $(LDFLAGS) $(LDFLAGS_pcap.o)
 #XXX: The call below does not work because the flags are added before the
 # object name, so nothing from the library gets linked.
 #$(call if_changed,ld)
diff -puN arch/um/scripts/Makefile.unmap~uml-pcap-on-64bit-host arch/um/scripts/Makefile.unmap
--- clean-linux-2.6.11/arch/um/scripts/Makefile.unmap~uml-pcap-on-64bit-host	2005-06-08 02:09:55.000000000 +0200
+++ clean-linux-2.6.11-paolo/arch/um/scripts/Makefile.unmap	2005-06-08 02:09:55.000000000 +0200
@@ -15,7 +15,7 @@ $(obj)/unmap.o: _c_flags = $(__UNMAP_CFL
 
 quiet_cmd_wrapld = LD      $@
 define cmd_wrapld
-	$(LD) $(LDFLAGS) -r -o $(obj)/unmap_tmp.o $< $(shell $(CC) -print-file-name=libc.a); \
+	$(LD) $(LDFLAGS) -r -o $(obj)/unmap_tmp.o $< $(shell $(CC) $(CFLAGS) -print-file-name=libc.a); \
 	$(OBJCOPY) $(UML_OBJCOPYFLAGS) $(obj)/unmap_tmp.o $@ -G switcheroo
 endef
 
_