From: Jeff D. <jd...@ka...> - 2000-03-21 17:08:53
|
> I tried to build uml-2.3.99-pre2 from sources, but failed. I just grabbed my patch from sourceforge and rebuilt a kernel, so it's not hopelessly bad :-) > moreover CVS and patch give different source trees. This surprises me a little, but not too much. My CVS discipline has not been the best in the past, although I added something to the -pre2 build which should have caught any lingering differences. I'll check this out and make CVS match the patch. > - um/kernel/irq.c references "linux/tasks.h" which does not > exists; This is true. I'll see if there's an easy way to prevent the compiler from looking in /usr/include (nostdinc does, but when I looked at that before, I thought there were nasty side-effects which couldn't be avoided). You can get rid of that include. > - many files (for example syscall_user.c) include both "asm/ > somefile.h" and "somefile.h" > which have conflicts (/usr/include/unistd.h from glibc 2.1.3 and > asm/unistd.h); This is ok. It should get /usr/include/asm/somefile.h and /usr/include/somefile.h. It should not get $(TOPDIR)/include/asm/somefile.h. and this is guaranteed by stripping that -I from the command line. This is the compile line for syscall_user.c: gcc -D__KERNEL__ -D__KERNEL__ -Wall -Wstrict-prototypes -O2 -g -U__i386__ -D__arch_um__ -fwritable-strings -fno-strict-aliasing -I../include -c -o syscall_user.o syscall_user.c The compiler has no way of finding the kernel headers. It gets system headers and what's in ../include. > The question is: where may I find good uml sources? The patch is as good as you're going to get from me :-) In order to fix this, I need to see your build output. If you want to look into this yourself, the thing you need to know is this: The uml sources are divided into user-space files, which include only system headers and no kernel headers, and kernel files, which include only kernel headers and no system headers. They communicate through headers that they both include, which are mostly located in arch/um/include (and a couple in arch/um/drivers). Compile problems happen when system headers sneak into kernel files or kernel headers sneak into user-space files. I've seen cases where I have a header missing from include/asm and the compiler finds the file in /usr/include/asm instead (and I'll check to see if -nostdinc will prevent that). The rewriting of CFLAGS to eliminate the -I$(TOPDIR)/include from user-space file compiles should prevent kernel headers from sneaking into them. Jeff |
From: Jeff D. <jd...@ka...> - 2000-03-21 17:15:14
|
> In the CVS: > - open_vt() from stdio_console_user.c conflicts with its prototype > and calling place. I just checked this out and I don't see a problem: This is the declaration: extern int open_vt(int n, int *pid_out); This is the call: static struct vt { int fd; int count; int xterm_pid; } vts[MAX_TTYS]; int line; vts[line].fd = open_vt(line, &vts[line].xterm_pid); I grabbed those snippets from the cvs browser: http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/linux/arch/um/drivers/stdio_conso le.h?rev=1.2&content-type=text/x-cvsweb-markup&cvsroot=user-mode-linux http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/linux/arch/um/drivers/stdio_cons ole.c?rev=1.6&content-type=text/x-cvsweb-markup&cvsroot=user-mode-linux Jeff |
From: Yuri P. <yu...@sw...> - 2000-03-21 19:54:02
|
Jeff Dike wrote: > > In the CVS: > > - open_vt() from stdio_console_user.c conflicts with its prototype > > and calling place. > > I just checked this out and I don't see a problem: > > This is the declaration: > extern int open_vt(int n, int *pid_out); > > This is the call: > static struct vt { > int fd; > int count; > int xterm_pid; > } vts[MAX_TTYS]; > > int line; > vts[line].fd = open_vt(line, &vts[line].xterm_pid); > > I grabbed those snippets from the cvs browser: > > http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/linux/arch/um/drivers/stdio_conso > le.h?rev=1.2&content-type=text/x-cvsweb-markup&cvsroot=user-mode-linux > http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/linux/arch/um/drivers/stdio_cons > ole.c?rev=1.6&content-type=text/x-cvsweb-markup&cvsroot=user-mode-linux > > Jeff From http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/linux/arch/um/drivers/stdio_console_user.c?rev=1.6&content-type=text/x-cvsweb-markup&cvsroot=user-mode-linux we see wrong open_vt() implementation: int open_vt(int n) { .... } Compile problem descriptions: My build environment uses customized Mandrake 7.0 installation: - glibc 2.1.3 - gcc 2.95.2. Pristine uml-2.3.99-pre2 cannot compile without $(TOPDIR)/include{linux,asm} symlinked to /usr/include/. make[1]: Entering directory `/usr/src/linux-2.3.99pre-uml/arch/um/kernel' gcc -D__KERNEL__ -D__KERNEL__ -Wall -Wstrict-prototypes -O2 -g -U__i386__ -D__arch_um__ -fwritable-strings -fno-strict-aliasing -I../include -c -o process.o process.c In file included from /usr/include/signal.h:294, from process.c:3: /usr/include/bits/sigcontext.h:28: asm/sigcontext.h: No such file or directory In file included from /usr/include/errno.h:36, from process.c:5: /usr/include/bits/errno.h:25: linux/errno.h: No such file or directory process.c:9: asm/ptrace.h: No such file or directory make[1]: *** [process.o] Error 1 I fixed this by adding -I$(HPATH) to USER_CFLAGS in um/kernel/Makefile 3) syscall_user.c and trap_user.c still do not compile: gcc -D__KERNEL__ -D__KERNEL__ -Wall -Wstrict-prototypes -O2 -g -U__i386__ -D__arch_um__ -fwritable-strings -fno-strict-aliasing -I/usr/src/linux-2.3.99pre-uml/include -I../include -c -o syscall_user.o syscall_user.c In file included from syscall_user.c:12: /usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:14: conflicting types for `open' /usr/include/fcntl.h:68: previous declaration of `open' /usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:21: conflicting types for `dup' /usr/include/unistd.h:437: previous declaration of `dup' /usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:28: conflicting types for `close' /usr/include/unistd.h:296: previous declaration of `close' /usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:35: conflicting types for `waitpid' /usr/include/sys/wait.h:132: previous declaration of `waitpid' make[1]: *** [syscall_user.o] Error 1 gcc -D__KERNEL__ -D__KERNEL__ -Wall -Wstrict-prototypes -O2 -g -U__i386__ -D__arch_um__ -fwritable-strings -fno-strict-aliasing -I/usr/src/linux-2.3.99pre-uml/include -I../include -c -o trap_user.o trap_user.c In file included from trap_user.c:11: /usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:21: conflicting types for `dup' /usr/include/unistd.h:437: previous declaration of `dup' /usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:28: conflicting types for `close' /usr/include/unistd.h:296: previous declaration of `close' /usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:32: parse error before `pid' /usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:32: warning: function declaration isn't a prototype /usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:34: parse error before `pid' /usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:35: conflicting types for `waitpid' /usr/include/sys/wait.h:132: previous declaration of `waitpid' /usr/src/linux-2.3.99pre-uml/include/asm/unistd.h: In function `waitpid': /usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:36: `pid' undeclared (first use in this function) /usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:36: (Each undeclared identifier is reported only once /usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:36: for each function it appears in.) /usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:36: `stat_addr' undeclared (first use in this function) /usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:36: `options' undeclared (first use in this function) After working around the above bugs (I commented out "include asm/unistd.h", leaving only libc unistd.h include), I finally got ./linux executable linked. It, however, segfaulted inside memcpy a bit after successfully opened "vm_file": ..... read(4, "n", 1) = 1 read(4, "u", 1) = 1 read(4, "x", 1) = 1 read(4, "\n", 1) = 1 open("vm_file", O_RDWR|O_CREAT|O_EXCL, 0777) = 6 unlink("vm_file") = 0 lseek(6, 618496, SEEK_SET) = 618496 write(6, "\0", 1) = 1 mmap(NULL, 618496, PROT_WRITE, MAP_SHARED, 6, 0) = 0x40000000 --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ Core was generated by `./linux '. Program terminated with signal 11, Segmentation fault. #0 0x1008ebf7 in memcpy () (gdb) bt #0 0x1008ebf7 in memcpy () Cannot access memory at address 0xbffff748 Unfortunatly, gdb does not show stack trace and line info. Any comments? |
From: Yuri P. <yu...@sw...> - 2000-03-21 21:51:22
|
I figured out how to locate the exact place of coredump. Then I run newly compiled uml-linux-2.3.99-pre2, it dumps core in memcpy at user_utils.c:156, after the first crearte_vm_file() call. The mistery is that both src and dst addresses for memcpy, as well as size seems to be reasonably correct. mmap() to dst is also successed. However memcpy call did not return, resulted in segfault. Here is a gdb session: Breakpoint 6, remap_data (perms=0x1015ef53 "rw-") at user_util.c:156 156 memcpy(addr, (void *) start, size); 1: x/i $eip 0x10084fa1 <remap_data+165>: mov 0xfffffff4(%ebp),%eax (gdb) list 151 data = create_vm_file(size); 152 if((addr = mmap(NULL, size, PROT_WRITE, MAP_SHARED, data, 0)) < 0){ 153 perror("mapping new data segment"); 154 exit(1); 155 } 156 memcpy(addr, (void *) start, size); 157 if(munmap((void *) start, size) < 0){ 158 perror("unmapping old data segment"); 159 exit(1); 160 } (gdb) p data $24 = 10 (gdb) p/x addr $25 = 0x40000000 (gdb) p/x size $26 = 0x97000 (gdb) p/x start $27 = 0x100d0000 (gdb) p/x 618496 $28 = 0x97000 (gdb) p ((char*)addr)[0] $29 = 0 '\000' (gdb) p ((char*)addr)[size-1] $30 = 0 '\000' (gdb) p ((char*)start)[size-1] $31 = 0 '\000' (gdb) p ((char*)start)[0] $32 = 0 '\000' (gdb) p $esp $33 = (void *) 0xbffff754 (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0x1008ebf9 in memcpy () 1: x/i $eip 0x1008ebf9 <memcpy+41>: mov 0x1c(%edi),%edx (gdb) p/x $edi $35 = 0x40001000 And the most interesting observation: the exact address at which program segfaulted depends on my print manipulations from gdb. I.e. if I do print ((char*)addr[0], it segfaulted at addr+0x1000, if I do touch also addr[0x1000], it segfaulted at addr+0x2000. In case I did not print at all, I got segfault @ 0x400000000. Got the point? FYI: I use 2.2.15-pre15 as a host kernel (with ptrace() syscall-overwrite patch). Will continue my efforts tomorrow, please help me with advise if you have some explanations. |
From: Yuri P. <yu...@sw...> - 2000-03-21 20:29:55
|
I just re-read you reply and finally found the root of my compiling problems: after unpacking and patching sources, I leaved /usr/src/linux symlink pointed to uml-linux source tree. This setup badly brokes your game with include paths, resulting in my problems described. So now I can cleanly compile uml-linux from clean 2.3.99-pre2 and your patch, with only one correction: - removed #include "linux/tasks.h" from irq.c But running linux executable still gives me core dump in the same place, still do not know why. And as I alraedy mentioned, CVS tree has outdated stdio_console_user.c file. Best regards, Yuri Pudgorodsky |