Date: Fri, 23 Oct 1998 11:02:11 +0800 From: Peter Wemm <peter@netplex.com.au> To: "David E. Cross" <crossd@cs.rpi.edu> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Begging to be asked (ELF Kernel) Message-ID: <199810230302.LAA24981@spinner.netplex.com.au> In-Reply-To: Your message of "Thu, 22 Oct 1998 22:51:28 -0400." <199810230251.WAA19680@o2.cs.rpi.edu>
index | next in thread | previous in thread | raw e-mail
"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
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810230302.LAA24981>