From owner-freebsd-current Wed Apr 22 03:01:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA08051 for freebsd-current-outgoing; Wed, 22 Apr 1998 03:01:03 -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 KAA08022 for ; Wed, 22 Apr 1998 10:00:50 GMT (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id RAA05222; Wed, 22 Apr 1998 17:59:29 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199804220959.RAA05222@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: John-Mark Gurney cc: Terry Lambert , current@FreeBSD.ORG Subject: Re: ELF kernels: When? In-reply-to: Your message of "Wed, 22 Apr 1998 00:45:18 MST." <19980422004518.25051@hydrogen.nike.efn.org> Date: Wed, 22 Apr 1998 17:59:28 +0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John-Mark Gurney wrote: > Terry Lambert scribbled this message on Apr 22: > > I would like to run an ELF kernel. > > > > Specifically, I would like to experiment with abstracting libkern > > as a seperate ELF segment in the running kernel that I could map > > into a program's address space via a section aware dlopen() (sort > > of a poor man's "libelf"). I would hack the loader to not load > > the (shared object) section type I'd use for this. > > > > This would tend to fix the !@#$%! "ps: proc size mismatch ..." > > messages, once and for all. > > > > So, per the subject: "ELF kernels: When?". > > well, one of the requirements to elf kernel is going to be link_elf.c > being writen... otherwide, elf kernels will NEVER happen (either elf > kernels or improved bus/device design)... so when will that happen? > > as far as elf kernels, I thought a few people were running the kernels > using jdp's elfkit... What, you mean like this? [..] cc -c -O -pipe -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wuninitialized -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf ../../i386/i386/setdef0.c cc -c -O -pipe -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wuninitialized -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf ../../i386/i386/setdef1.c sh ../../conf/newvers.sh BEAST cc -O -pipe -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wuninitialized -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf -c vers.c loading kernel text data bss dec hex filename 952005 65132 120004 1137141 1159f5 kernel peter@beast[4:39pm]~src/sys/compile/BEAST-128> file kernel kernel: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, not stripped [also:] peter@beast[4:40pm]~src/sys/compile/BEAST-129> file /kernel /kernel: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, not stripped The real problems are: - The bootblocks do not load the ELF symbol table, so DDB can't see it. - DDB doesn't understand the ELF symbol tables yet anyway. - the bootblocks have *zero* bytes free at present. There is ELF load code available, but you have to disable BAD144 to get it to fit. Restructuring the code so that the #ifdefs are not too messy tips the bootblocks over the limit by a few bytes. - The loader is quite simple, it pulls in the text and data LOAD sections, without any of the section headers etc. Those section headers and string tables are needed to do proper runtime linking via link_elf.c. > -- > John-Mark Gurney Modem Rev/FAX: +1 541 346 9237 > Cu Networking P.O. Box 5693, 97405 > > Live in Peace, destroy Micro$oft, support free software, run FreeBSD > Don't trust anyone you don't have the source for > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > Cheers, -Peter -- Peter Wemm Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message