From: J. B. F. <bf...@fi...> - 2003-11-04 23:18:55
|
Recently uml compiles have started failing under debian/unstable. I suspect it's the fault of a recent glibc upgrade, and that a debian list would be the more appropriate place to ask, but perhaps someone here will have some enlightenment: arch/um/sys-i386/bugs.c: In function `disable_lcall': arch/um/sys-i386/bugs.c:110: error: storage size of `ldt' isn't known arch/um/sys-i386/bugs.c:117: warning: implicit declaration of function `modify_ldt' arch/um/sys-i386/bugs.c:110: warning: unused variable `ldt' I can insert a definition for struct modify_ldt_ldt_s (the type of "ldt"), but then I get a segfault on boot: (gdb) bt #0 0xa02bfaf0 in __libc_setup_tls () #1 0xa02bfdfb in __pthread_initialize_minimal () #2 0x00000004 in ?? () #3 0xbffff4b8 in ?? () #4 0xa02bf8b4 in __libc_start_main () Previous frame inner to this frame (corrupt stack?) --Bruce Fields |
From: BlaisorBlade <bla...@ya...> - 2003-11-11 18:52:11
|
Alle 00:18, mercoled=EC 5 novembre 2003, J. Bruce Fields ha scritto: > Recently uml compiles have started failing under debian/unstable. I > suspect it's the fault of a recent glibc upgrade, and that a debian list > would be the more appropriate place to ask, but perhaps someone here > will have some enlightenment: > > arch/um/sys-i386/bugs.c: In function `disable_lcall': > arch/um/sys-i386/bugs.c:110: error: storage size of `ldt' isn't known > arch/um/sys-i386/bugs.c:117: warning: implicit declaration of function > `modify_ldt' > arch/um/sys-i386/bugs.c:110: warning: unused variable `ldt' > > I can insert a definition for struct modify_ldt_ldt_s (the type of > "ldt"), but then I get a segfault on boot: You mean inserting "the RIGHT definition" or a silly one? This is the correct definition: struct modify_ldt_ldt_s { unsigned int entry_number; unsigned long base_addr; unsigned int limit; unsigned int seg_32bit:1; unsigned int contents:2; unsigned int read_exec_only:1; unsigned int limit_in_pages:1; unsigned int seg_not_present:1; unsigned int useable:1; }; Also, this comes from /usr/include/asm headers(the ones from kernel), i.e. = if=20 glibc people change it, they are silly. So they didn't, probably. But which is your current version of glibc? I have the 2.3.1 Would you do a find /usr/include|xargs grep modify_ldt_ldt_s to see where = is=20 it declared? If the declarations are there and in the right=20 file(/usr/include/asm/ldt.h), then maybe the include file is not found. Maybe they've decided to follow the man page of modify_ldt, which documents= as=20 header linux/ldt.h... Bye and thanks! > (gdb) bt > #0 0xa02bfaf0 in __libc_setup_tls () > #1 0xa02bfdfb in __pthread_initialize_minimal () > #2 0x00000004 in ?? () > #3 0xbffff4b8 in ?? () > #4 0xa02bf8b4 in __libc_start_main () Gdb 6.0? It's not clear what a such backtrace mean, even if my experience w= ith=20 6.0 says that the ?? "frames" it reports are just values in the stack and n= ot=20 frames. =2D-=20 cat <<EOSIGN Paolo Giarrusso, aka Blaisorblade Linux Kernel 2.4.21/2.6.0-test on an i686; Linux registered user n. 292729 EOSIGN |
From: J. B. F. <bf...@fi...> - 2003-11-11 20:16:10
|
On Sun, Nov 09, 2003 at 04:17:44PM +0100, BlaisorBlade wrote: > Alle 00:18, mercoledì 5 novembre 2003, J. Bruce Fields ha scritto: > > Recently uml compiles have started failing under debian/unstable. I > > suspect it's the fault of a recent glibc upgrade, and that a debian list > > would be the more appropriate place to ask, but perhaps someone here > > will have some enlightenment: > > > > arch/um/sys-i386/bugs.c: In function `disable_lcall': > > arch/um/sys-i386/bugs.c:110: error: storage size of `ldt' isn't known > > arch/um/sys-i386/bugs.c:117: warning: implicit declaration of function > > `modify_ldt' > > arch/um/sys-i386/bugs.c:110: warning: unused variable `ldt' > > > > I can insert a definition for struct modify_ldt_ldt_s (the type of > > "ldt"), but then I get a segfault on boot: > You mean inserting "the RIGHT definition" or a silly one? The right one, yup. The definition of modify_ldt also seems to have diseappeared, so I added a _syscall3(int, modify_ldt, int, func, void *, ptr, unsigned long, bytecount); too. I doubt any of this matters, since I believe the uml segfaults long before it'd have a chance to actually execute that code: bfields@puzzle:linux-2.6.0-test9$ strace ./linux execve("./linux", ["./linux"], [/* 28 vars */]) = 0 uname({sys="Linux", node="puzzle", ...}) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ > But which is your current version of glibc? I have the 2.3.1 The version on the debian package is 2.3.2.ds1-10 > Would you do a find /usr/include|xargs grep modify_ldt_ldt_s to see where is > it declared? If the declarations are there and in the right > file(/usr/include/asm/ldt.h), then maybe the include file is not found. A grep on /usr/include turns up nothing. The file ldt.h is still there, but is a copy from the 2.6 tree: /* * ldt.h * * Definitions of structures used with the modify_ldt system call. */ #ifndef _LINUX_LDT_H #define _LINUX_LDT_H /* Maximum number of LDT entries supported. */ #define LDT_ENTRIES 8192 /* The size of each LDT entry. */ #define LDT_ENTRY_SIZE 8 #ifndef __ASSEMBLY__ struct user_desc { unsigned int entry_number; unsigned long base_addr; unsigned int limit; unsigned int seg_32bit:1; unsigned int contents:2; unsigned int read_exec_only:1; unsigned int limit_in_pages:1; unsigned int seg_not_present:1; unsigned int useable:1; }; #define MODIFY_LDT_CONTENTS_DATA 0 #define MODIFY_LDT_CONTENTS_STACK 1 #define MODIFY_LDT_CONTENTS_CODE 2 #endif /* !__ASSEMBLY__ */ #endif > > (gdb) bt > > #0 0xa02bfaf0 in __libc_setup_tls () > > #1 0xa02bfdfb in __pthread_initialize_minimal () > > #2 0x00000004 in ?? () > > #3 0xbffff4b8 in ?? () > > #4 0xa02bf8b4 in __libc_start_main () > Gdb 6.0? Yup. > It's not clear what a such backtrace mean, even if my experience with > 6.0 says that the ?? "frames" it reports are just values in the stack and not > frames. I'm not quite sure how to even start debugging this problem...--b. |
From: BlaisorBlade <bla...@ya...> - 2003-11-15 18:00:47
|
See the last message which appeared... the workaround is to make /usr/include/{asm,asm-generic,linux} to be symlinks into kernel sources, and success was reported(by another Debian user). However, this must be removed for user-space programs, as it's known broken(see kernel sources main README). Then, I compared the ldt.h from 2.6 and 2.4. Everything but the structure hasn't changed(modify_ldt decl. comes from somewhere else, if it is present at all). This means that either Debian or glibc maintainer should either rename back the structure for userspace headers(since the name is documented in man pages) or add a #define(but the second may break some other uses of the modify_ldt_ldt_s identifier, if any, so it's not wise). You should test if adding a such #define in the UML files solves the problem. However, the Debian maintainer shouldn't compile glibc against a 2.6 kernel, at least until a such kernel isn't shipped. -- cat <<EOSIGN Paolo Giarrusso, aka Blaisorblade Linux Kernel 2.4.21/2.6.0-test on an i686; Linux registered user n. 292729 EOSIGN |
From: J. B. F. <bf...@fi...> - 2003-11-16 01:48:46
|
On Sat, Nov 15, 2003 at 07:03:45PM +0100, BlaisorBlade wrote: > See the last message which appeared... the workaround is to make > /usr/include/{asm,asm-generic,linux} to be symlinks into kernel sources, and > success was reported(by another Debian user). However, this must be removed > for user-space programs, as it's known broken(see kernel sources main > README). Hrm. This doesn't solve anything for me--I still get the immediate segfault in __libc_setup_tls. --Bruce Fields |
From: Jeff D. <jd...@ad...> - 2003-11-16 03:54:03
|
bf...@fi... said: > Hrm. This doesn't solve anything for me--I still get the immediate > segfault in __libc_setup_tls. That's completely separate. There's a fix in 2.4 which I haven't moved up to 2.6 yet. Both linker scripts (arch/um/{dyn,uml}.lds.S) have this near the top: . = ALIGN(4096); __binary_start = .; Get rid of the ALIGN line and the tls problem will go away. Jeff |
From: J. B. F. <bf...@fi...> - 2003-11-16 04:31:55
|
On Fri, Nov 14, 2003 at 10:49:16AM -0500, Jeff Dike wrote: > bf...@fi... said: > > Hrm. This doesn't solve anything for me--I still get the immediate > > segfault in __libc_setup_tls. > > That's completely separate. There's a fix in 2.4 which I haven't moved up > to 2.6 yet. > > Both linker scripts (arch/um/{dyn,uml}.lds.S) have this near the top: > > . = ALIGN(4096); > __binary_start = .; > > Get rid of the ALIGN line and the tls problem will go away. Ah, yep, that did it. Thanks! --Bruce Fields |