Date: Wed, 22 Apr 1998 22:30:33 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Chris Csanady <ccsanady@friley585.res.iastate.edu> Cc: Peter Wemm <peter@netplex.com.au>, John-Mark Gurney <gurney_j@resnet.uoregon.edu>, Terry Lambert <tlambert@primenet.com>, current@FreeBSD.ORG Subject: Re: ELF kernels: When? Message-ID: <Pine.BSF.3.95q.980422222253.21783H-100000@herring.nlsystems.com> In-Reply-To: <199804221354.IAA02372@friley585.res.iastate.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 22 Apr 1998, Chris Csanady wrote: > > >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. All thats really needed is the pathname to /kernel (or whatever happened to boot). The startup code in link_elf.c (link_elf_init() if its anything like link_aout.c) can grovel around in /kernel to get its symbol table. Alternatively use the same technique as link_aout and link the kernel as a shared elf object (which just happened not to be linked against any other shared objects). The linker will place the runtime symbol table in a LOAD section and will fix _DYNAMIC to point at the start of the ".dynamic" section. link_elf_init() can then walk the list of DT_XXX entries in the dynamic section to find the symbol table and everything else. This code for parsing ".dynamic" will be the same code as that used to dynamically load an elf module. Then to top things off nicely, fix DDB to use the kernel linker to manage its symbol table (you would need to add some code to the kernel linker for this). > > So, does anyone know enough about bootblocks to look at integrating NetBSD's? > They have done a significant amount of work in this area it seems, and they > already have a two-stage design. Trying to squeeze every last bit out of > the current blocks seems futile.. I looked at them once about a year ago. They ought to work without too much trouble. > > Are there any arguments against doing this? Whats the license on the NetBSD boot code? -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 Fax: +44 181 381 1039 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.980422222253.21783H-100000>