From: Blaisorblade <bla...@ya...> - 2005-06-08 18:07:26
|
On Wednesday 08 June 2005 19:38, Nix wrote: > On Wed, 8 Jun 2005, bla...@ya... said: > > On Tuesday 07 June 2005 21:47, Nix wrote: > >> On Tue, 7 Jun 2005, bla...@ya... 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. > > OK, will do. > > >> 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): > > Unlikely: this isn't an x86-64 box ;} No, I thought it was a general error... > > 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! > [snip] > > > 60c00000-a2000000 rwxs ffffffffc0c00000 00:0e > > 1383102 /tmp/vm_file-JmW1nY (deleted) > Whaa? Yes, strange offset... it's what I noted too. > >> Looks like a thread initialization problem to *me*. And there be very > >> serious and nasty snarling dragons with sharp pointy carborundum teeth > > This kind of problems is normally caused from wrong alignments in the > > linker script. > I'm not surprised it dies: even ld can see that something's wrong. With > V=1 we see this: > gcc -static -Wl,--wrap,malloc -Wl,--wrap,free -Wl,--wrap,calloc -o > vmlinux -Wl,-T,arch/um/kernel/vmlinux.lds init/built-in.o > -Wl,--start-group usr/built-in.o arch/um/kernel/built-in.o > arch/um/drivers/built-in.o arch/um/os-Linux/built-in.o > arch/um/sys-i386/built-in.o arch/i386/crypto/built-in.o kernel/built-in.o > mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o > crypto/built-in.o lib/lib.a lib/built-in.o drivers/built-in.o > sound/built-in.o net/built-in.o -Wl,--end-group -lutil .tmp_kallsyms3.o ; > rm -f linux /usr/bin/ld: BFD 2.16.90.0.3 20050510 assertion fail elf.c:3833 Only with V=1 the error is shown? Strange! Also, why the hell is this assertion failing, in normal words? Is he complaining for the (now missing) .thread_private section? Also, would you be able to fix problems like "allocated 5 headers, needed 6" or such? What are the criteria for choosing how many headers to allocate? > which is the assertion here, inside > bfd/elf.c:map_sections_to_segments(): > > /* If there are any SHF_TLS output sections, add PT_TLS segment. */ > if (tls_count > 0) > { > int i; > > amt = sizeof (struct elf_segment_map); > amt += (tls_count - 1) * sizeof (asection *); > m = bfd_zalloc (abfd, amt); > if (m == NULL) > goto error_return; > m->next = NULL; > m->p_type = PT_TLS; > m->count = tls_count; > /* Mandated PF_R. */ > m->p_flags = PF_R; > m->p_flags_valid = 1; > for (i = 0; i < tls_count; ++i) > { > BFD_ASSERT (first_tls->flags & SEC_THREAD_LOCAL); > m->sections[i] = first_tls; > first_tls = first_tls->next; > } > > *pm = m; > pm = &m->next; > } > > Btw, I forgot that broken-out is in perfect state and would help more for > > debug... > > I'll try that next. Here I've attached the patch that today worked for me; it replaces the one with the same name, and I applied until it. Please, take care that there is no dependency yet from unmap_fin.o to vmlinux, so modifying that file won't show up in the final result unless you either tocuh arch/um/kernel/vmlinux.lds or (untested) rm .tmp_vmlinux1. > > Global warming, isn't it? However don't worry, the Gulf Current is going > > to stop so you'll get refreshed of -10 degrees... > Excellent. Bring back the ice age! > (Hm. My house wouldn't stand up well under a kilometre of ice...) Everybody gets a free new house! Global warming is the next killer application for house building! -- 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 |