From owner-freebsd-current Thu Oct 22 20:04:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA12422 for freebsd-current-outgoing; Thu, 22 Oct 1998 20:04:59 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA12413 for ; Thu, 22 Oct 1998 20:04:41 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.1/8.9.1/Spinner) with ESMTP id LAA24981; Fri, 23 Oct 1998 11:02:11 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199810230302.LAA24981@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: "David E. Cross" cc: freebsd-current@FreeBSD.ORG Subject: Re: Begging to be asked (ELF Kernel) In-reply-to: Your message of "Thu, 22 Oct 1998 22:51:28 -0400." <199810230251.WAA19680@o2.cs.rpi.edu> Date: Fri, 23 Oct 1998 11:02:11 +0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "David E. Cross" wrote: > Today I went to an ELF kernel, flawless, 3rd stage boot is wonderfull, many > thanks to all involved, great job! > > I do have one[two] question[s]: > > *phoenix / $ file /kernel > /kernel: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), > dynamically linked, not stripped > > _dynamically linked_?? Heh. :-) Don't panic, it just means that it's got the data tables present that are mainly intended for ld.so. The in-kernel equivalent of ld.so uses these when loading kernel modules. > Curiosity got to me so I tried: > *phoenix / $ ldd /kernel > /kernel: > /kernel: signal 6 > > signal 6 is 'sigabrt'. > > So my 2 questions are: 1)Why is the kernel dynamically linked, and 2) why ca n > I not ldd the kernel (I coppied the file to another place and attempted to ld d > that un-live kernel as well, no dice) ldd is an a.out tool. What you want is: 122> objdump --all-headers /kernel | more /kernel: file format elf32-i386 /kernel architecture: i386, flags 0x00000112: EXEC_P, HAS_SYMS, D_PAGED start address 0xf011a460 Program Header: PHDR off 0x00000034 vaddr 0xf0100034 paddr 0xf0100034 align 2**2 filesz 0x000000a0 memsz 0x000000a0 flags r-x INTERP off 0x000000d4 vaddr 0xf01000d4 paddr 0xf01000d4 align 2**0 filesz 0x0000000d memsz 0x0000000d flags r-- LOAD off 0x00000000 vaddr 0xf0100000 paddr 0xf0100000 align 2**12 filesz 0x0013d790 memsz 0x0013d790 flags r-x LOAD off 0x0013d790 vaddr 0xf023e790 paddr 0xf023e790 align 2**12 filesz 0x0001519c memsz 0x00041d84 flags rw- DYNAMIC off 0x001528ec vaddr 0xf02538ec paddr 0xf02538ec align 2**2 filesz 0x00000040 memsz 0x00000040 flags rw- Dynamic Section: NEEDED hack.so HASH 0xf01000e4 STRTAB 0xf0110f5c SYMTAB 0xf01050ac STRSZ 0x94fd SYMENT 0x10 DEBUG 0x0 [..] "hack.so" is a red herring used to trick binutils ld into producing a dynamic object even though it's not actually used at link time. Note that the kernel is **not** PIC like shared libraries, so don't panic about the slowdown that PIC causes due to the loss of %ebx and the jump table indirection. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message