I re-wrote the compile script to build klibc (cleaning up how I do it, and how to find the source tarballs). It seems to be compiling fine. I tried several of the commands in usr/utils/static and most one. However, the sleep command fails in a strange way (EINVAL on execve): ===============================================================faraday/phil /home/phil/klibc-project-0 581> strace -ftt -s 96 klibc-1.5.18/usr/utils/static/true 07:33:08.185542 execve("klibc-1.5.18/usr/utils/static/true", ["klibc-1.5.18/usr/utils/static/true"], [/* 38 vars */]) = 0 07:33:08.185880 _exit(0) = ? Process 29017 detached faraday/phil /home/phil/klibc-project-0 582> strace -ftt -s 96 klibc-1.5.18/usr/utils/static/sleep 6 07:33:10.636524 execve("klibc-1.5.18/usr/utils/static/sleep", ["klibc-1.5.18/usr/utils/static/sleep", "6"], [/* 38 vars */]) = -1 EINVAL (Invalid argument) 07:33:10.636930 +++ killed by SIGKILL +++ Process 29020 detached faraday/phil /home/phil/klibc-project-0 583> ldd klibc-1.5.18/usr/utils/static/true klibc-1.5.18/usr/utils/static/sleep klibc-1.5.18/usr/utils/static/true: not a dynamic executable klibc-1.5.18/usr/utils/static/sleep: not a dynamic executable faraday/phil /home/phil/klibc-project-0 584> file klibc-1.5.18/usr/utils/static/true klibc-1.5.18/usr/utils/static/sleep klibc-1.5.18/usr/utils/static/true: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped klibc-1.5.18/usr/utils/static/sleep: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped faraday/phil /home/phil/klibc-project-0 585> ls -dl klibc-1.5.18/usr/utils/static/true klibc-1.5.18/usr/utils/static/sleep -rwxr-xr-x 1 phil phil 4168 2010-07-14 07:17 klibc-1.5.18/usr/utils/static/sleep -rwxr-xr-x 1 phil phil 548 2010-07-14 07:17 klibc-1.5.18/usr/utils/static/true faraday/phil /home/phil/klibc-project-0 586> =============================================================== I'm guessing execve thinks this can't be executed for some reason. Even so, SIGKILL seems strange (shouldn't the shell forked child just report the execve failure, instead?). Any ideas where I should look, next?
On Wed, Jul 14, 2010 at 07:34:46AM -0400, Phil Howard wrote:> I re-wrote the compile script to build klibc (cleaning up how I do it, > and how to find the source tarballs).why would there be a need for this. this seems just like a waste of time.> It seems to be compiling fine. > I tried several of the commands in usr/utils/static and most one. > However, the sleep command fails in a strange way (EINVAL on execve):why doesn't this surprise me!? works just fine here ./usr/utils/static/sleep 0.1> ===============================================================> faraday/phil /home/phil/klibc-project-0 581> strace -ftt -s 96 > klibc-1.5.18/usr/utils/static/true > 07:33:08.185542 execve("klibc-1.5.18/usr/utils/static/true", > ["klibc-1.5.18/usr/utils/static/true"], [/* 38 vars */]) = 0 > 07:33:08.185880 _exit(0) = ? > Process 29017 detached > faraday/phil /home/phil/klibc-project-0 582> strace -ftt -s 96 > klibc-1.5.18/usr/utils/static/sleep 6 > 07:33:10.636524 execve("klibc-1.5.18/usr/utils/static/sleep", > ["klibc-1.5.18/usr/utils/static/sleep", "6"], [/* 38 vars */]) = -1 > EINVAL (Invalid argument) > 07:33:10.636930 +++ killed by SIGKILL +++ > Process 29020 detached > faraday/phil /home/phil/klibc-project-0 583> ldd > klibc-1.5.18/usr/utils/static/true klibc-1.5.18/usr/utils/static/sleep > klibc-1.5.18/usr/utils/static/true: > not a dynamic executable > klibc-1.5.18/usr/utils/static/sleep: > not a dynamic executable > faraday/phil /home/phil/klibc-project-0 584> file > klibc-1.5.18/usr/utils/static/true klibc-1.5.18/usr/utils/static/sleep > klibc-1.5.18/usr/utils/static/true: ELF 32-bit LSB executable, Intel > 80386, version 1 (SYSV), statically linked, stripped > klibc-1.5.18/usr/utils/static/sleep: ELF 32-bit LSB executable, Intel > 80386, version 1 (SYSV), statically linked, stripped > faraday/phil /home/phil/klibc-project-0 585> ls -dl > klibc-1.5.18/usr/utils/static/true klibc-1.5.18/usr/utils/static/sleep > -rwxr-xr-x 1 phil phil 4168 2010-07-14 07:17 klibc-1.5.18/usr/utils/static/sleep > -rwxr-xr-x 1 phil phil 548 2010-07-14 07:17 klibc-1.5.18/usr/utils/static/true > faraday/phil /home/phil/klibc-project-0 586> > ===============================================================strace -ftt -s 96 ./usr/utils/static/sleep 0.1 18:30:11.741777 execve("./usr/utils/static/sleep", ["./usr/utils/static/sleep", "0.1"], [/* 45 vars */]) = 0 18:30:11.742627 nanosleep({0, 100000000}, 0x7fff9b1ac720) = 0 18:30:11.842925 _exit(0) = ?> I'm guessing execve thinks this can't be executed for some reason. > Even so, SIGKILL seems strange (shouldn't the shell forked child just > report the execve failure, instead?). Any ideas where I should look, > next?axe your wrong built and do it the recommended way.
On Thu, Jul 15, 2010 at 12:02:15PM +0200, maximilian attems wrote:> On Wed, Jul 14, 2010 at 07:47:43PM -0400, Phil Howard wrote: > > > > > axe your wrong built and do it the recommended way. > > > > Can you put the recommended way into some kind of complete document? > > sure, here the quick way. It assumes you have a ~src directory in > your home as common practise. nproc is found in recent coreutils (8.1). > > in short words the recommend way is to built klibc against > configured linux-2.6 tree: > > cd ~/src > git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > cd linux-2.6 > make defconfig > make -j $(nproc)# uncomplete, forgot to get back in ~/src cd ..> git clone git://git.kernel.org/pub/scm/libs/klibc/klibc.git > cd klibc > make KLIBCKERNELSRC=`pwd`/../linux-2.6 -j $(nproc) > > ./usr/utils/static/sleep 0.5 > > > happy hacking.
On Wed, Jul 14, 2010 at 7:34 AM, Phil Howard <kunnskaperen at gmail.com> wrote:> I re-wrote the compile script to build klibc (cleaning up how I do it, > and how to find the source tarballs). It seems to be compiling fine. > I tried several of the commands in usr/utils/static and most one. > However, the sleep command fails in a strange way (EINVAL on execve): > > ===============================================================> faraday/phil /home/phil/klibc-project-0 581> strace -ftt -s 96 > klibc-1.5.18/usr/utils/static/true > 07:33:08.185542 execve("klibc-1.5.18/usr/utils/static/true", > ["klibc-1.5.18/usr/utils/static/true"], [/* 38 vars */]) = 0 > 07:33:08.185880 _exit(0) = ? > Process 29017 detached > faraday/phil /home/phil/klibc-project-0 582> strace -ftt -s 96 > klibc-1.5.18/usr/utils/static/sleep 6 > 07:33:10.636524 execve("klibc-1.5.18/usr/utils/static/sleep", > ["klibc-1.5.18/usr/utils/static/sleep", "6"], [/* 38 vars */]) = -1 > EINVAL (Invalid argument) > 07:33:10.636930 +++ killed by SIGKILL +++ > Process 29020 detached > faraday/phil /home/phil/klibc-project-0 583> ldd > klibc-1.5.18/usr/utils/static/true klibc-1.5.18/usr/utils/static/sleep > klibc-1.5.18/usr/utils/static/true: > not a dynamic executable > klibc-1.5.18/usr/utils/static/sleep: > not a dynamic executable > faraday/phil /home/phil/klibc-project-0 584> file > klibc-1.5.18/usr/utils/static/true klibc-1.5.18/usr/utils/static/sleep > klibc-1.5.18/usr/utils/static/true: ELF 32-bit LSB executable, Intel > 80386, version 1 (SYSV), statically linked, stripped > klibc-1.5.18/usr/utils/static/sleep: ELF 32-bit LSB executable, Intel > 80386, version 1 (SYSV), statically linked, stripped > faraday/phil /home/phil/klibc-project-0 585> ls -dl > klibc-1.5.18/usr/utils/static/true klibc-1.5.18/usr/utils/static/sleep > -rwxr-xr-x 1 phil phil 4168 2010-07-14 07:17 klibc-1.5.18/usr/utils/static/sleep > -rwxr-xr-x 1 phil phil 548 2010-07-14 07:17 klibc-1.5.18/usr/utils/static/true > faraday/phil /home/phil/klibc-project-0 586> > ===============================================================> > I'm guessing execve thinks this can't be executed for some reason. > Even so, SIGKILL seems strange (shouldn't the shell forked child just > report the execve failure, instead?). Any ideas where I should look, > next? >I've narrowed down why the kernel won't execute it. A load address violates the ELF alignment requirement. Why the linker made this, I have no idea. Why it did so ONLY for the sleep command is curious (I checked them all and only the sleep command is broken). I'll next try to setup a newer binutils (the script I'm writing will later be building a binutils from source as part of the process). Here is the "readelf -a" output for the broken sleep command. See the 2nd "LOAD" type line. It should be 0x000f64. ===============================================================ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Intel 80386 Version: 0x1 Entry point address: 0x8048094 Start of program headers: 52 (bytes into file) Start of section headers: 3968 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 3 Size of section headers: 40 (bytes) Number of section headers: 5 Section header string table index: 4 Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .text PROGBITS 08048094 000094 000ce0 00 AX 0 0 4 [ 2] .rodata PROGBITS 08048d80 000d80 0001e1 00 A 0 0 32 [ 3] .bss NOBITS 08049f64 000f61 000014 00 WA 0 0 4 [ 4] .shstrtab STRTAB 00000000 000f61 00001e 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) There are no section groups in this file. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x08048000 0x08048000 0x00f61 0x00f61 R E 0x1000 LOAD 0x000f61 0x08049f64 0x08049f64 0x00000 0x00014 RW 0x1000 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4 Section to Segment mapping: Segment Sections... 00 .text .rodata 01 .bss 02 There is no dynamic section in this file. There are no relocations in this file. There are no unwind sections in this file. No version information found in this file. ================================================================