Compiling Fiasco UX problems under Fedora 8
Hello I'm currently trying compil curent Fiasco UX under a Fedora 8 unfortunatly I get this: Linking test mapdb_t g++ -static -Wl,--gc-sections,-T/home/olivier/l4/kernel/fiasco/src/kernel.ux.ld \ -fno-implement-inlines -mpreferred-stack-boundary=2 -m32 -march=i686 -fno-defer-pop -freg-struct-return -g -Wall -W -Wno-parentheses -Wformat=2 -fno-stack-protector -ffunction-sections -gstabs+ -fno-rtti -fno-exceptions -fno-threadsafe-statics -Wno-non-virtual-dtor -O2 --param large-function-insns=10000 -fweb -finline-limit=10000 -frename-registers -fgcse-after-reload \ mapdb_t.o mapdb.o simpleio.o kernel_console.o panic.o warn.o buddy_alloc.o mem_layout.o mem_layout-ux.o per_cpu_data.o globals.o globals-ia32-ux.o loader.o vhw.o kip_init-ia32-amd64-ux.o kip_init-ux.o boot_info.o boot_info-ia32-amd64-ux.o boot_info-ux.o cmdline.o config.o config-ia32-ux.o config-ux.o jdb_symbol.o jdb_util.o tb_entry.o tb_entry-ia32-ux.o perf_cnt.o perf_cnt-ia32-ux.o jdb_tbuf.o x86desc.o emulation.o pic.o pic-ux.o usermode.o cpu-common.o cpu-ia32-ux.o cpu-ux.o trampoline.o cpu_lock.o cpu_lock-generic.o region.o entry_frame.o entry_frame-ia32-ux.o entry_frame-abs-timeout-hack.o kmem-ia32-ux.o kmem-ux.o mapped_alloc.o mem_unit-ux.o ram_quota.o kmem_alloc.o kmem_alloc-ia32-amd64-ux.o per_cpu_data_alloc.o slab_cache_anon.o kmem_slab_simple.o vmem_alloc.o vmem_alloc-ia32-ux.o vmem_alloc-ux.o paging.o paging-ia32-ux.o kmem_slab.o fpu_state.o fpu.o fpu-ia32-ux.o fpu-ux.o sched_context.o switch_lock.o timer.o timer-ia32-amd64-ux.o timer-ux.o timeout.o space_index.o obj_space.o cap_space.o mem_space.o mem_space-user.o mem_space-ia32-ux.o mem_space-ux.o space.o space-caps.o space-ux.o context.o context-ia32-ux.o context-ux.o helping_lock.o cap_space_alloc.o obj_space_alloc.o mapping-ia32-ux.o mapping.o mapping_tree.o libabi.a libjabi.a libdrivers.a libk.a libamm.a libcxx.a sighandler.o -o mapdb_t Running test mapdb_t ... /bin/sh: line 1: 24293 Erreur de segmentation ./mapdb_t --test --quiet > mapdb_t.out make[1]: *** [mapdb_t.ok] Erreur 139 make[1]: quittant le répertoire « /home/olivier/l4/kernel/fiasco/build » make: *** [all] Erreur 2 The Fiasco ux have been compiled but it is the same error I receive in console only an: Segmentation error Nothing more. any idea? Olivier --
Hi, On Sun Mar 09, 2008 at 23:23:12 +0100, Olivier.Landemarre@utbm.fr wrote:
I'm currently trying compil curent Fiasco UX under a Fedora 8 unfortunatly I get this:
Linking test mapdb_t g++ -static -Wl,--gc-sections,-T/home/olivier/l4/kernel/fiasco/src/kernel.ux.ld \ -fno-implement-inlines -mpreferred-stack-boundary=2 -m32 -march=i686 -fno-defer-pop -freg-struct-return -g -Wall -W -Wno-parentheses -Wformat=2 -fno-stack-protector -ffunction-sections -gstabs+ -fno-rtti -fno-exceptions -fno-threadsafe-statics -Wno-non-virtual-dtor -O2 --param large-function-insns=10000 -fweb -finline-limit=10000 -frename-registers -fgcse-after-reload \ mapdb_t.o mapdb.o simpleio.o kernel_console.o panic.o warn.o buddy_alloc.o mem_layout.o mem_layout-ux.o per_cpu_data.o globals.o globals-ia32-ux.o loader.o vhw.o kip_init-ia32-amd64-ux.o kip_init-ux.o boot_info.o boot_info-ia32-amd64-ux.o boot_info-ux.o cmdline.o config.o config-ia32-ux.o config-ux.o jdb_symbol.o jdb_util.o tb_entry.o tb_entry-ia32-ux.o perf_cnt.o perf_cnt-ia32-ux.o jdb_tbuf.o x86desc.o emulation.o pic.o pic-ux.o usermode.o cpu-common.o cpu-ia32-ux.o cpu-ux.o trampoline.o cpu_lock.o cpu_lock-generic.o region.o entry_frame.o entry_frame-ia32-ux.o entry_frame-abs-timeout-hack.o kmem-ia32-ux.o kmem-ux.o mapped_alloc.o mem_unit-ux.o ram_quota.o kmem_alloc.o kmem_alloc-ia32-amd64-ux.o per_cpu_data_alloc.o slab_cache_anon.o kmem_slab_simple.o vmem_alloc.o vmem_alloc-ia32-ux.o vmem_alloc-ux.o paging.o paging-ia32-ux.o kmem_slab.o fpu_state.o fpu.o fpu-ia32-ux.o fpu-ux.o sched_context.o switch_lock.o timer.o timer-ia32-amd64-ux.o timer-ux.o timeout.o space_index.o obj_space.o cap_space.o mem_space.o mem_space-user.o mem_space-ia32-ux.o mem_space-ux.o space.o space-caps.o space-ux.o context.o context-ia32-ux.o context-ux.o helping_lock.o cap_space_alloc.o obj_space_alloc.o mapping-ia32-ux.o mapping.o mapping_tree.o libabi.a libjabi.a libdrivers.a libk.a libamm.a libcxx.a sighandler.o -o mapdb_t Running test mapdb_t ... /bin/sh: line 1: 24293 Erreur de segmentation ./mapdb_t --test --quiet > mapdb_t.out make[1]: *** [mapdb_t.ok] Erreur 139 make[1]: quittant le répertoire « /home/olivier/l4/kernel/fiasco/build » make: *** [all] Erreur 2
The Fiasco ux have been compiled but it is the same error I receive in console only an: Segmentation error Nothing more.
any idea?
This seems to be very specific to FC8 as this doesn't happen to me and to our automatic builds. Can you discover what causes the segfaults? You can also send me one of the binaries that segfault to analyze. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
This seems to be very specific to FC8 as this doesn't happen to me and to our automatic builds. Can you discover what causes the segfaults? You can also send me one of the binaries that segfault to analyze.
with gdb I have this informations running fiasco: Program received signal SIGSEGV, Segmentation fault. 0x00039bee in __libc_setup_tls () at /home/olivier/l4/kernel/fiasco/src/drivers/ux/processor-ux.cpp:47 47 asm volatile (" .byte 0xf3, 0x90 #pause \n" ); I have currently an AMD Athlon processor If I try with mapdb_t, I have this Program received signal SIGSEGV, Segmentation fault. 0x00043b8e in __libc_setup_tls () at /home/olivier/l4/kernel/fiasco/src/kern/kmem_alloc.cpp:74 74 assert(o>=8 /*NEW INTERFACE PARANIOIA*/); I can send binary Olivier
On Mon Mar 10, 2008 at 18:16:41 +0100, Olivier.Landemarre@utbm.fr wrote:
This seems to be very specific to FC8 as this doesn't happen to me and to our automatic builds. Can you discover what causes the segfaults? You can also send me one of the binaries that segfault to analyze.
with gdb I have this informations running fiasco:
Program received signal SIGSEGV, Segmentation fault. 0x00039bee in __libc_setup_tls () at /home/olivier/l4/kernel/fiasco/src/drivers/ux/processor-ux.cpp:47 47 asm volatile (" .byte 0xf3, 0x90 #pause \n" );
I have currently an AMD Athlon processor
If I try with mapdb_t, I have this
Program received signal SIGSEGV, Segmentation fault. 0x00043b8e in __libc_setup_tls () at /home/olivier/l4/kernel/fiasco/src/kern/kmem_alloc.cpp:74 74 assert(o>=8 /*NEW INTERFACE PARANIOIA*/);
I can send binary
Ok, I'll look at it. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
On Mon Mar 10, 2008 at 18:16:41 +0100, Olivier.Landemarre@utbm.fr wrote:
This seems to be very specific to FC8 as this doesn't happen to me and to our automatic builds. Can you discover what causes the segfaults? You can also send me one of the binaries that segfault to analyze.
with gdb I have this informations running fiasco:
Program received signal SIGSEGV, Segmentation fault. 0x00039bee in __libc_setup_tls () at /home/olivier/l4/kernel/fiasco/src/drivers/ux/processor-ux.cpp:47 47 asm volatile (" .byte 0xf3, 0x90 #pause \n" );
I have currently an AMD Athlon processor
If I try with mapdb_t, I have this
Program received signal SIGSEGV, Segmentation fault. 0x00043b8e in __libc_setup_tls () at /home/olivier/l4/kernel/fiasco/src/kern/kmem_alloc.cpp:74 74 assert(o>=8 /*NEW INTERFACE PARANIOIA*/);
I can send binary
I've looked a bit into this and it's a pointer deref that goes wrong (AFAICS) inside the glibc code. I'd guess a FC8 system is now needed... Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
On Wed Mar 12, 2008 at 13:02:46 +0100, Adam Lackorzynski wrote:
On Mon Mar 10, 2008 at 18:16:41 +0100, Olivier.Landemarre@utbm.fr wrote:
This seems to be very specific to FC8 as this doesn't happen to me and to our automatic builds. Can you discover what causes the segfaults? You can also send me one of the binaries that segfault to analyze.
with gdb I have this informations running fiasco:
Program received signal SIGSEGV, Segmentation fault. 0x00039bee in __libc_setup_tls () at /home/olivier/l4/kernel/fiasco/src/drivers/ux/processor-ux.cpp:47 47 asm volatile (" .byte 0xf3, 0x90 #pause \n" );
I have currently an AMD Athlon processor
If I try with mapdb_t, I have this
Program received signal SIGSEGV, Segmentation fault. 0x00043b8e in __libc_setup_tls () at /home/olivier/l4/kernel/fiasco/src/kern/kmem_alloc.cpp:74 74 assert(o>=8 /*NEW INTERFACE PARANIOIA*/);
I can send binary
I've looked a bit into this and it's a pointer deref that goes wrong (AFAICS) inside the glibc code. I'd guess a FC8 system is now needed...
I can reproduce this in FC8 and _dl_phdr seems to be initialized with the wrong value very early in the glibc startup. I don't know why. The next step would probably be to recompile glibc with some more debugging code added and see what's happening. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
Adam Lackorzynski a écrit :
On Wed Mar 12, 2008 at 13:02:46 +0100, Adam Lackorzynski wrote:
On Mon Mar 10, 2008 at 18:16:41 +0100, Olivier.Landemarre@utbm.fr wrote:
This seems to be very specific to FC8 as this doesn't happen to me and to our automatic builds. Can you discover what causes the segfaults? You can also send me one of the binaries that segfault to analyze.
with gdb I have this informations running fiasco:
Program received signal SIGSEGV, Segmentation fault. 0x00039bee in __libc_setup_tls () at /home/olivier/l4/kernel/fiasco/src/drivers/ux/processor-ux.cpp:47 47 asm volatile (" .byte 0xf3, 0x90 #pause \n" );
I have currently an AMD Athlon processor
If I try with mapdb_t, I have this
Program received signal SIGSEGV, Segmentation fault. 0x00043b8e in __libc_setup_tls () at /home/olivier/l4/kernel/fiasco/src/kern/kmem_alloc.cpp:74 74 assert(o>=8 /*NEW INTERFACE PARANIOIA*/);
I can send binary
I've looked a bit into this and it's a pointer deref that goes wrong (AFAICS) inside the glibc code. I'd guess a FC8 system is now needed...
I can reproduce this in FC8 and _dl_phdr seems to be initialized with the wrong value very early in the glibc startup. I don't know why. The next step would probably be to recompile glibc with some more debugging code added and see what's happening.
Ok, I'm unfortunatly not enough good to help you, I'm afraid. Regards Olivier
Adam
participants (3)
-
Adam Lackorzynski -
Olivier Landemarre -
Olivier.Landemarre＠utbm.fr