d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
30e8350c60
freebsd-skq/sys/boot/common/load_elf.c

742 lines
20 KiB
C
Raw Normal View History

ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
/*-
* Copyright (c) 1998 Michael Smith <msmith@freebsd.org>
* Copyright (c) 1998 Peter Wemm <peter@freebsd.org>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
Use __FBSDID(). Also some minor style cleanups.
2003-08-25 23:30:41 +00:00
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
#include <sys/param.h>
#include <sys/exec.h>
Implement preloading for elf modules - get dependency info from PT_DYNAMIC's DT_NEEDED tags. - store MODINFOMD_DYNAMIC for the kernel's later use setenv kernelname when we have it Fix firstaddr/lastaddr calculation (duh! :-) Explicitly skip string table with section names in it.
1998-10-09 23:18:43 +00:00
#include <sys/linker.h>
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
#include <sys/module.h>
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
#include <string.h>
#include <machine/elf.h>
#include <stand.h>
#define FREEBSD_ELF
#include <link.h>
#include "bootstrap.h"
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
#define COPYOUT(s,d,l) archsw.arch_copyout((vm_offset_t)(s), d, l)
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
#if defined(__i386__) && __ELF_WORD_SIZE == 64
#undef ELF_TARG_CLASS
#undef ELF_TARG_MACH
#define ELF_TARG_CLASS ELFCLASS64
#define ELF_TARG_MACH EM_X86_64
#endif
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
typedef struct elf_file {
Elf_Phdr *ph;
Elf_Ehdr *ehdr;
Elf_Sym *symtab;
Use the correct elf hash table entry type. This matches a similar fix in the kernel side of things some time ago. The hash table entries are always 32 bits wide, even on 64 bit machines.
2002-04-06 04:09:42 +00:00
Elf_Hashelt *hashtab;
Elf_Hashelt nbuckets;
Elf_Hashelt nchains;
Elf_Hashelt *buckets;
Elf_Hashelt *chains;
Fix module dependency (pre)loading on sparc64 by relocating the variables read from the raw kld files. Submitted by: Hartmut Brandt <brandt@fokus.gmd.de> PR: 46870 Tested on: alpha (obrien), i386, sparc64
2003-01-21 05:46:46 +00:00
Elf_Rela *rela;
size_t relasz;
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
char *strtab;
size_t strsz;
int fd;
caddr_t firstpage;
Cleanup warnings. Most of these are signed/unsigned warnings, as well as some added const's.
2000-08-03 09:14:02 +00:00
size_t firstlen;
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
int kernel;
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
u_int64_t off;
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
} *elf_file_t;
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
static int __elfN(loadimage)(struct preloaded_file *mp, elf_file_t ef, u_int64_t loadaddr);
static int __elfN(lookup_symbol)(struct preloaded_file *mp, elf_file_t ef, const char* name, Elf_Sym* sym);
Fix module dependency (pre)loading on sparc64 by relocating the variables read from the raw kld files. Submitted by: Hartmut Brandt <brandt@fokus.gmd.de> PR: 46870 Tested on: alpha (obrien), i386, sparc64
2003-01-21 05:46:46 +00:00
#ifdef __sparc__
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
static void __elfN(reloc_ptr)(struct preloaded_file *mp, elf_file_t ef,
Fix module dependency (pre)loading on sparc64 by relocating the variables read from the raw kld files. Submitted by: Hartmut Brandt <brandt@fokus.gmd.de> PR: 46870 Tested on: alpha (obrien), i386, sparc64
2003-01-21 05:46:46 +00:00
void *p, void *val, size_t len);
#endif
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
static int __elfN(parse_modmetadata)(struct preloaded_file *mp, elf_file_t ef);
Cleanup warnings. Most of these are signed/unsigned warnings, as well as some added const's.
2000-08-03 09:14:02 +00:00
static char *fake_modname(const char *name);
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
const char *__elfN(kerneltype) = "elf kernel";
const char *__elfN(moduletype) = "elf module";
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
/*
* Attempt to load the file (file) as an ELF module. It will be stored at
* (dest), and a pointer to a module structure describing the loaded object
* will be saved in (result).
*/
int
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
__elfN(loadfile)(char *filename, u_int64_t dest, struct preloaded_file **result)
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
{
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
struct preloaded_file *fp, *kfp;
struct elf_file ef;
Elf_Ehdr *ehdr;
int err;
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
u_int pad;
Cleanup warnings. Most of these are signed/unsigned warnings, as well as some added const's.
2000-08-03 09:14:02 +00:00
ssize_t bytes_read;
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
fp = NULL;
bzero(&ef, sizeof(struct elf_file));
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
/*
* Open the image, read and validate the ELF header
*/
if (filename == NULL) /* can't handle nameless */
return(EFTYPE);
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
if ((ef.fd = open(filename, O_RDONLY)) == -1)
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
return(errno);
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
ef.firstpage = malloc(PAGE_SIZE);
if (ef.firstpage == NULL) {
close(ef.fd);
Load the first page of the file and use the headers in it. This should avoid the need to seek back to offset zero which is causing trouble on the Alpha with a gzipped kernel.
1998-10-17 03:06:38 +00:00
return(ENOMEM);
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
}
Cleanup warnings. Most of these are signed/unsigned warnings, as well as some added const's.
2000-08-03 09:14:02 +00:00
bytes_read = read(ef.fd, ef.firstpage, PAGE_SIZE);
ef.firstlen = (size_t)bytes_read;
if (bytes_read < 0 || ef.firstlen <= sizeof(Elf_Ehdr)) {
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
err = EFTYPE; /* could be EIO, but may be small file */
goto oerr;
}
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
ehdr = ef.ehdr = (Elf_Ehdr *)ef.firstpage;
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
/* Is it ELF? */
Load the first page of the file and use the headers in it. This should avoid the need to seek back to offset zero which is causing trouble on the Alpha with a gzipped kernel.
1998-10-17 03:06:38 +00:00
if (!IS_ELF(*ehdr)) {
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
err = EFTYPE;
goto oerr;
}
Load the first page of the file and use the headers in it. This should avoid the need to seek back to offset zero which is causing trouble on the Alpha with a gzipped kernel.
1998-10-17 03:06:38 +00:00
if (ehdr->e_ident[EI_CLASS] != ELF_TARG_CLASS || /* Layout ? */
ehdr->e_ident[EI_DATA] != ELF_TARG_DATA ||
ehdr->e_ident[EI_VERSION] != EV_CURRENT || /* Version ? */
ehdr->e_version != EV_CURRENT ||
ehdr->e_machine != ELF_TARG_MACH) { /* Machine ? */
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
err = EFTYPE;
goto oerr;
}
/*
* Check to see what sort of module we are.
*/
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
kfp = file_findfile(NULL, NULL);
Load the first page of the file and use the headers in it. This should avoid the need to seek back to offset zero which is causing trouble on the Alpha with a gzipped kernel.
1998-10-17 03:06:38 +00:00
if (ehdr->e_type == ET_DYN) {
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
/* Looks like a kld module */
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
if (kfp == NULL) {
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
printf("elf" __XSTRING(__ELF_WORD_SIZE) "_loadfile: can't load module before kernel\n");
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
err = EPERM;
goto oerr;
}
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
if (strcmp(__elfN(kerneltype), kfp->f_type)) {
printf("elf" __XSTRING(__ELF_WORD_SIZE) "_loadfile: can't load module with kernel type '%s'\n", kfp->f_type);
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
err = EPERM;
goto oerr;
}
/* Looks OK, got ahead */
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
ef.kernel = 0;
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
/* Page-align the load address */
Implement preloading for elf modules - get dependency info from PT_DYNAMIC's DT_NEEDED tags. - store MODINFOMD_DYNAMIC for the kernel's later use setenv kernelname when we have it Fix firstaddr/lastaddr calculation (duh! :-) Explicitly skip string table with section names in it.
1998-10-09 23:18:43 +00:00
pad = (u_int)dest & PAGE_MASK;
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
if (pad != 0) {
pad = PAGE_SIZE - pad;
Implement preloading for elf modules - get dependency info from PT_DYNAMIC's DT_NEEDED tags. - store MODINFOMD_DYNAMIC for the kernel's later use setenv kernelname when we have it Fix firstaddr/lastaddr calculation (duh! :-) Explicitly skip string table with section names in it.
1998-10-09 23:18:43 +00:00
dest += pad;
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
}
Load the first page of the file and use the headers in it. This should avoid the need to seek back to offset zero which is causing trouble on the Alpha with a gzipped kernel.
1998-10-17 03:06:38 +00:00
} else if (ehdr->e_type == ET_EXEC) {
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
/* Looks like a kernel */
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
if (kfp != NULL) {
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
printf("elf" __XSTRING(__ELF_WORD_SIZE) "_loadfile: kernel already loaded\n");
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
err = EPERM;
goto oerr;
}
/*
* Calculate destination address based on kernel entrypoint
*/
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
dest = ehdr->e_entry;
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
if (dest == 0) {
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
printf("elf" __XSTRING(__ELF_WORD_SIZE) "_loadfile: not a kernel (maybe static binary?)\n");
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
err = EPERM;
goto oerr;
}
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
ef.kernel = 1;
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
} else {
err = EFTYPE;
goto oerr;
}
/*
* Ok, we think we should handle this.
*/
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
fp = file_alloc();
if (fp == NULL) {
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
printf("elf" __XSTRING(__ELF_WORD_SIZE) "_loadfile: cannot allocate module info\n");
Implement preloading for elf modules - get dependency info from PT_DYNAMIC's DT_NEEDED tags. - store MODINFOMD_DYNAMIC for the kernel's later use setenv kernelname when we have it Fix firstaddr/lastaddr calculation (duh! :-) Explicitly skip string table with section names in it.
1998-10-09 23:18:43 +00:00
err = EPERM;
goto out;
}
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
if (ef.kernel)
Implement preloading for elf modules - get dependency info from PT_DYNAMIC's DT_NEEDED tags. - store MODINFOMD_DYNAMIC for the kernel's later use setenv kernelname when we have it Fix firstaddr/lastaddr calculation (duh! :-) Explicitly skip string table with section names in it.
1998-10-09 23:18:43 +00:00
setenv("kernelname", filename, 1);
Implement the long-awaited module->file cache database. A userland tool (kldxref(8)) keeps a cache of what modules and versions are inside what .ko files. I have tested this on both Alpha and i386. Submitted by: bp
2001-09-11 01:09:24 +00:00
fp->f_name = strdup(filename);
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
fp->f_type = strdup(ef.kernel ? __elfN(kerneltype) : __elfN(moduletype));
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
Make the ELF load messages cleaner.
1998-10-13 09:25:27 +00:00
#ifdef ELF_VERBOSE
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
if (ef.kernel)
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
printf("%s entry at 0x%jx\n", filename, (uintmax_t)dest);
Tweak the output one more time again. The kernel or module pathname is useful, and usually fits all on one line with the load sizes.
1998-10-14 00:41:17 +00:00
#else
printf("%s ", filename);
Make the ELF load messages cleaner.
1998-10-13 09:25:27 +00:00
#endif
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
fp->f_size = __elfN(loadimage)(fp, &ef, dest);
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
if (fp->f_size == 0 || fp->f_addr == 0)
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
goto ioerr;
/* save exec header as metadata */
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
file_addmetadata(fp, MODINFOMD_ELFHDR, sizeof(*ehdr), ehdr);
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
/* Load OK, return module pointer */
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
*result = (struct preloaded_file *)fp;
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
err = 0;
goto out;
ioerr:
err = EIO;
oerr:
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
file_discard(fp);
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
out:
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
if (ef.firstpage)
free(ef.firstpage);
close(ef.fd);
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
return(err);
}
/*
* With the file (fd) open on the image, and (ehdr) containing
Implement preloading for elf modules - get dependency info from PT_DYNAMIC's DT_NEEDED tags. - store MODINFOMD_DYNAMIC for the kernel's later use setenv kernelname when we have it Fix firstaddr/lastaddr calculation (duh! :-) Explicitly skip string table with section names in it.
1998-10-09 23:18:43 +00:00
* the Elf header, load the image at (off)
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
*/
static int
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
__elfN(loadimage)(struct preloaded_file *fp, elf_file_t ef, u_int64_t off)
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
{
Cleanup warnings. Most of these are signed/unsigned warnings, as well as some added const's.
2000-08-03 09:14:02 +00:00
int i;
u_int j;
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
Elf_Ehdr *ehdr;
Elf_Phdr *phdr, *php;
First shot at loading elf symbols. Things are a bit strange because of the ..umm.. "wierd" way binutils lays out the file. The section headers are nearly at the end of the file and this is a problem when loading from a .gz file which can't seek backwards (or has a limited reverse seek, ~2K from memory). This is intended to be compatable with the ddb/db_elf.c code and the alpha/libalpha/elf_freebsd.c layout. I've studied these (which are NetBSD derived) but did it a bit differently. Naturally the process is similar since it's supposed to end up with the same result.
1998-10-02 08:04:56 +00:00
Elf_Shdr *shdr;
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
int ret;
vm_offset_t firstaddr;
vm_offset_t lastaddr;
void *buf;
First shot at loading elf symbols. Things are a bit strange because of the ..umm.. "wierd" way binutils lays out the file. The section headers are nearly at the end of the file and this is a problem when loading from a .gz file which can't seek backwards (or has a limited reverse seek, ~2K from memory). This is intended to be compatable with the ddb/db_elf.c code and the alpha/libalpha/elf_freebsd.c layout. I've studied these (which are NetBSD derived) but did it a bit differently. Naturally the process is similar since it's supposed to end up with the same result.
1998-10-02 08:04:56 +00:00
size_t resid, chunk;
Cleanup warnings. Most of these are signed/unsigned warnings, as well as some added const's.
2000-08-03 09:14:02 +00:00
ssize_t result;
First shot at loading elf symbols. Things are a bit strange because of the ..umm.. "wierd" way binutils lays out the file. The section headers are nearly at the end of the file and this is a problem when loading from a .gz file which can't seek backwards (or has a limited reverse seek, ~2K from memory). This is intended to be compatable with the ddb/db_elf.c code and the alpha/libalpha/elf_freebsd.c layout. I've studied these (which are NetBSD derived) but did it a bit differently. Naturally the process is similar since it's supposed to end up with the same result.
1998-10-02 08:04:56 +00:00
vm_offset_t dest;
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
Elf_Addr ssym, esym;
Implement preloading for elf modules - get dependency info from PT_DYNAMIC's DT_NEEDED tags. - store MODINFOMD_DYNAMIC for the kernel's later use setenv kernelname when we have it Fix firstaddr/lastaddr calculation (duh! :-) Explicitly skip string table with section names in it.
1998-10-09 23:18:43 +00:00
Elf_Dyn *dp;
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
Elf_Addr adp;
Implement preloading for elf modules - get dependency info from PT_DYNAMIC's DT_NEEDED tags. - store MODINFOMD_DYNAMIC for the kernel's later use setenv kernelname when we have it Fix firstaddr/lastaddr calculation (duh! :-) Explicitly skip string table with section names in it.
1998-10-09 23:18:43 +00:00
int ndp;
Only print kernel entry point during load. Drastically quieten down the verbose load progress messages. They were more useful for debugging than anything, but are beyond a joke when loading a few dozen modules. Simplify the ELF extended symbol table load format. Just take the main symbol table and the string table that corresponds. This is what we will be getting local symbols from. (needed for the alpha stack tracebacks). Use the (optional) full symbol tables in lookups. This means we have to furhter distinguish between symbols that can come from the dynamic linking table and the complete table. The alpha boot code now needs to be adapted as ddb/db_elf.c cannot use the simpler format. I have not implemented loading the extended symbol tables from the syscall interface yet, just for preloaded modules. I am not sure about the symbol resolution. I *think* it's possible that a local symbol can be found in preference to a global, depending on the search sequence and dependency tree.
1998-10-12 09:13:50 +00:00
int symstrindex;
int symtabindex;
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
Elf_Size size;
Cleanup warnings. Most of these are signed/unsigned warnings, as well as some added const's.
2000-08-03 09:14:02 +00:00
u_int fpcopy;
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
Implement preloading for elf modules - get dependency info from PT_DYNAMIC's DT_NEEDED tags. - store MODINFOMD_DYNAMIC for the kernel's later use setenv kernelname when we have it Fix firstaddr/lastaddr calculation (duh! :-) Explicitly skip string table with section names in it.
1998-10-09 23:18:43 +00:00
dp = NULL;
shdr = NULL;
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
ret = 0;
firstaddr = lastaddr = 0;
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
ehdr = ef->ehdr;
if (ef->kernel) {
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
#ifdef __i386__
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
#if __ELF_WORD_SIZE == 64
off = - (off & 0xffffffffff000000ull);/* x86_64 relocates after locore */
#else
Enable load of i386 ELF kernels with larger KVA range (e.g. starting at 0xe0100000u or 0xc0100000u instead of the usual 0xf0100000u).
1999-02-15 17:36:58 +00:00
off = - (off & 0xff000000u); /* i386 relocates after locore */
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
#endif
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
#else
off = 0; /* alpha is direct mapped for kernels */
#endif
Implement preloading for elf modules - get dependency info from PT_DYNAMIC's DT_NEEDED tags. - store MODINFOMD_DYNAMIC for the kernel's later use setenv kernelname when we have it Fix firstaddr/lastaddr calculation (duh! :-) Explicitly skip string table with section names in it.
1998-10-09 23:18:43 +00:00
}
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
ef->off = off;
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
if ((ehdr->e_phoff + ehdr->e_phnum * sizeof(*phdr)) > ef->firstlen) {
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
printf("elf" __XSTRING(__ELF_WORD_SIZE) "_loadimage: program header not within first page\n");
Load the first page of the file and use the headers in it. This should avoid the need to seek back to offset zero which is causing trouble on the Alpha with a gzipped kernel.
1998-10-17 03:06:38 +00:00
goto out;
}
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
phdr = (Elf_Phdr *)(ef->firstpage + ehdr->e_phoff);
Load the first page of the file and use the headers in it. This should avoid the need to seek back to offset zero which is causing trouble on the Alpha with a gzipped kernel.
1998-10-17 03:06:38 +00:00
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
for (i = 0; i < ehdr->e_phnum; i++) {
/* We want to load PT_LOAD segments only.. */
if (phdr[i].p_type != PT_LOAD)
continue;
Only print kernel entry point during load. Drastically quieten down the verbose load progress messages. They were more useful for debugging than anything, but are beyond a joke when loading a few dozen modules. Simplify the ELF extended symbol table load format. Just take the main symbol table and the string table that corresponds. This is what we will be getting local symbols from. (needed for the alpha stack tracebacks). Use the (optional) full symbol tables in lookups. This means we have to furhter distinguish between symbols that can come from the dynamic linking table and the complete table. The alpha boot code now needs to be adapted as ddb/db_elf.c cannot use the simpler format. I have not implemented loading the extended symbol tables from the syscall interface yet, just for preloaded modules. I am not sure about the symbol resolution. I *think* it's possible that a local symbol can be found in preference to a global, depending on the search sequence and dependency tree.
1998-10-12 09:13:50 +00:00
#ifdef ELF_VERBOSE
First shot at loading elf symbols. Things are a bit strange because of the ..umm.. "wierd" way binutils lays out the file. The section headers are nearly at the end of the file and this is a problem when loading from a .gz file which can't seek backwards (or has a limited reverse seek, ~2K from memory). This is intended to be compatable with the ddb/db_elf.c code and the alpha/libalpha/elf_freebsd.c layout. I've studied these (which are NetBSD derived) but did it a bit differently. Naturally the process is similar since it's supposed to end up with the same result.
1998-10-02 08:04:56 +00:00
printf("Segment: 0x%lx@0x%lx -> 0x%lx-0x%lx",
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
(long)phdr[i].p_filesz, (long)phdr[i].p_offset,
(long)(phdr[i].p_vaddr + off),
First shot at loading elf symbols. Things are a bit strange because of the ..umm.. "wierd" way binutils lays out the file. The section headers are nearly at the end of the file and this is a problem when loading from a .gz file which can't seek backwards (or has a limited reverse seek, ~2K from memory). This is intended to be compatable with the ddb/db_elf.c code and the alpha/libalpha/elf_freebsd.c layout. I've studied these (which are NetBSD derived) but did it a bit differently. Naturally the process is similar since it's supposed to end up with the same result.
1998-10-02 08:04:56 +00:00
(long)(phdr[i].p_vaddr + off + phdr[i].p_memsz - 1));
Only print kernel entry point during load. Drastically quieten down the verbose load progress messages. They were more useful for debugging than anything, but are beyond a joke when loading a few dozen modules. Simplify the ELF extended symbol table load format. Just take the main symbol table and the string table that corresponds. This is what we will be getting local symbols from. (needed for the alpha stack tracebacks). Use the (optional) full symbol tables in lookups. This means we have to furhter distinguish between symbols that can come from the dynamic linking table and the complete table. The alpha boot code now needs to be adapted as ddb/db_elf.c cannot use the simpler format. I have not implemented loading the extended symbol tables from the syscall interface yet, just for preloaded modules. I am not sure about the symbol resolution. I *think* it's possible that a local symbol can be found in preference to a global, depending on the search sequence and dependency tree.
1998-10-12 09:13:50 +00:00
#else
Make the ELF load messages cleaner.
1998-10-13 09:25:27 +00:00
if ((phdr[i].p_flags & PF_W) == 0) {
printf("text=0x%lx ", (long)phdr[i].p_filesz);
} else {
printf("data=0x%lx", (long)phdr[i].p_filesz);
if (phdr[i].p_filesz < phdr[i].p_memsz)
printf("+0x%lx", (long)(phdr[i].p_memsz -phdr[i].p_filesz));
printf(" ");
}
Only print kernel entry point during load. Drastically quieten down the verbose load progress messages. They were more useful for debugging than anything, but are beyond a joke when loading a few dozen modules. Simplify the ELF extended symbol table load format. Just take the main symbol table and the string table that corresponds. This is what we will be getting local symbols from. (needed for the alpha stack tracebacks). Use the (optional) full symbol tables in lookups. This means we have to furhter distinguish between symbols that can come from the dynamic linking table and the complete table. The alpha boot code now needs to be adapted as ddb/db_elf.c cannot use the simpler format. I have not implemented loading the extended symbol tables from the syscall interface yet, just for preloaded modules. I am not sure about the symbol resolution. I *think* it's possible that a local symbol can be found in preference to a global, depending on the search sequence and dependency tree.
1998-10-12 09:13:50 +00:00
#endif
Load the first page of the file and use the headers in it. This should avoid the need to seek back to offset zero which is causing trouble on the Alpha with a gzipped kernel.
1998-10-17 03:06:38 +00:00
fpcopy = 0;
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
if (ef->firstlen > phdr[i].p_offset) {
fpcopy = ef->firstlen - phdr[i].p_offset;
archsw.arch_copyin(ef->firstpage + phdr[i].p_offset,
Load the first page of the file and use the headers in it. This should avoid the need to seek back to offset zero which is causing trouble on the Alpha with a gzipped kernel.
1998-10-17 03:06:38 +00:00
phdr[i].p_vaddr + off, fpcopy);
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
}
Load the first page of the file and use the headers in it. This should avoid the need to seek back to offset zero which is causing trouble on the Alpha with a gzipped kernel.
1998-10-17 03:06:38 +00:00
if (phdr[i].p_filesz > fpcopy) {
Cleanup warnings. Most of these are signed/unsigned warnings, as well as some added const's.
2000-08-03 09:14:02 +00:00
if (lseek(ef->fd, (off_t)(phdr[i].p_offset + fpcopy),
SEEK_SET) == -1) {
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
printf("\nelf" __XSTRING(__ELF_WORD_SIZE) "_loadexec: cannot seek\n");
Load the first page of the file and use the headers in it. This should avoid the need to seek back to offset zero which is causing trouble on the Alpha with a gzipped kernel.
1998-10-17 03:06:38 +00:00
goto out;
}
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
if (archsw.arch_readin(ef->fd, phdr[i].p_vaddr + off + fpcopy,
Cleanup warnings. Most of these are signed/unsigned warnings, as well as some added const's.
2000-08-03 09:14:02 +00:00
phdr[i].p_filesz - fpcopy) != (ssize_t)(phdr[i].p_filesz - fpcopy)) {
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
printf("\nelf" __XSTRING(__ELF_WORD_SIZE) "_loadexec: archsw.readin failed\n");
Load the first page of the file and use the headers in it. This should avoid the need to seek back to offset zero which is causing trouble on the Alpha with a gzipped kernel.
1998-10-17 03:06:38 +00:00
goto out;
}
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
}
/* clear space from oversized segments; eg: bss */
if (phdr[i].p_filesz < phdr[i].p_memsz) {
Only print kernel entry point during load. Drastically quieten down the verbose load progress messages. They were more useful for debugging than anything, but are beyond a joke when loading a few dozen modules. Simplify the ELF extended symbol table load format. Just take the main symbol table and the string table that corresponds. This is what we will be getting local symbols from. (needed for the alpha stack tracebacks). Use the (optional) full symbol tables in lookups. This means we have to furhter distinguish between symbols that can come from the dynamic linking table and the complete table. The alpha boot code now needs to be adapted as ddb/db_elf.c cannot use the simpler format. I have not implemented loading the extended symbol tables from the syscall interface yet, just for preloaded modules. I am not sure about the symbol resolution. I *think* it's possible that a local symbol can be found in preference to a global, depending on the search sequence and dependency tree.
1998-10-12 09:13:50 +00:00
#ifdef ELF_VERBOSE
First shot at loading elf symbols. Things are a bit strange because of the ..umm.. "wierd" way binutils lays out the file. The section headers are nearly at the end of the file and this is a problem when loading from a .gz file which can't seek backwards (or has a limited reverse seek, ~2K from memory). This is intended to be compatable with the ddb/db_elf.c code and the alpha/libalpha/elf_freebsd.c layout. I've studied these (which are NetBSD derived) but did it a bit differently. Naturally the process is similar since it's supposed to end up with the same result.
1998-10-02 08:04:56 +00:00
printf(" (bss: 0x%lx-0x%lx)",
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
(long)(phdr[i].p_vaddr + off + phdr[i].p_filesz),
(long)(phdr[i].p_vaddr + off + phdr[i].p_memsz - 1));
Only print kernel entry point during load. Drastically quieten down the verbose load progress messages. They were more useful for debugging than anything, but are beyond a joke when loading a few dozen modules. Simplify the ELF extended symbol table load format. Just take the main symbol table and the string table that corresponds. This is what we will be getting local symbols from. (needed for the alpha stack tracebacks). Use the (optional) full symbol tables in lookups. This means we have to furhter distinguish between symbols that can come from the dynamic linking table and the complete table. The alpha boot code now needs to be adapted as ddb/db_elf.c cannot use the simpler format. I have not implemented loading the extended symbol tables from the syscall interface yet, just for preloaded modules. I am not sure about the symbol resolution. I *think* it's possible that a local symbol can be found in preference to a global, depending on the search sequence and dependency tree.
1998-10-12 09:13:50 +00:00
#endif
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
First shot at loading elf symbols. Things are a bit strange because of the ..umm.. "wierd" way binutils lays out the file. The section headers are nearly at the end of the file and this is a problem when loading from a .gz file which can't seek backwards (or has a limited reverse seek, ~2K from memory). This is intended to be compatable with the ddb/db_elf.c code and the alpha/libalpha/elf_freebsd.c layout. I've studied these (which are NetBSD derived) but did it a bit differently. Naturally the process is similar since it's supposed to end up with the same result.
1998-10-02 08:04:56 +00:00
/* no archsw.arch_bzero */
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
buf = malloc(PAGE_SIZE);
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
if (buf == NULL) {
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
printf("\nelf" __XSTRING(__ELF_WORD_SIZE) "_loadimage: malloc() failed\n");
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
goto out;
}
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
bzero(buf, PAGE_SIZE);
resid = phdr[i].p_memsz - phdr[i].p_filesz;
dest = phdr[i].p_vaddr + off + phdr[i].p_filesz;
while (resid > 0) {
chunk = min(PAGE_SIZE, resid);
archsw.arch_copyin(buf, dest, chunk);
resid -= chunk;
dest += chunk;
}
free(buf);
}
Only print kernel entry point during load. Drastically quieten down the verbose load progress messages. They were more useful for debugging than anything, but are beyond a joke when loading a few dozen modules. Simplify the ELF extended symbol table load format. Just take the main symbol table and the string table that corresponds. This is what we will be getting local symbols from. (needed for the alpha stack tracebacks). Use the (optional) full symbol tables in lookups. This means we have to furhter distinguish between symbols that can come from the dynamic linking table and the complete table. The alpha boot code now needs to be adapted as ddb/db_elf.c cannot use the simpler format. I have not implemented loading the extended symbol tables from the syscall interface yet, just for preloaded modules. I am not sure about the symbol resolution. I *think* it's possible that a local symbol can be found in preference to a global, depending on the search sequence and dependency tree.
1998-10-12 09:13:50 +00:00
#ifdef ELF_VERBOSE
First shot at loading elf symbols. Things are a bit strange because of the ..umm.. "wierd" way binutils lays out the file. The section headers are nearly at the end of the file and this is a problem when loading from a .gz file which can't seek backwards (or has a limited reverse seek, ~2K from memory). This is intended to be compatable with the ddb/db_elf.c code and the alpha/libalpha/elf_freebsd.c layout. I've studied these (which are NetBSD derived) but did it a bit differently. Naturally the process is similar since it's supposed to end up with the same result.
1998-10-02 08:04:56 +00:00
printf("\n");
Only print kernel entry point during load. Drastically quieten down the verbose load progress messages. They were more useful for debugging than anything, but are beyond a joke when loading a few dozen modules. Simplify the ELF extended symbol table load format. Just take the main symbol table and the string table that corresponds. This is what we will be getting local symbols from. (needed for the alpha stack tracebacks). Use the (optional) full symbol tables in lookups. This means we have to furhter distinguish between symbols that can come from the dynamic linking table and the complete table. The alpha boot code now needs to be adapted as ddb/db_elf.c cannot use the simpler format. I have not implemented loading the extended symbol tables from the syscall interface yet, just for preloaded modules. I am not sure about the symbol resolution. I *think* it's possible that a local symbol can be found in preference to a global, depending on the search sequence and dependency tree.
1998-10-12 09:13:50 +00:00
#endif
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
Implement preloading for elf modules - get dependency info from PT_DYNAMIC's DT_NEEDED tags. - store MODINFOMD_DYNAMIC for the kernel's later use setenv kernelname when we have it Fix firstaddr/lastaddr calculation (duh! :-) Explicitly skip string table with section names in it.
1998-10-09 23:18:43 +00:00
if (firstaddr == 0 || firstaddr > (phdr[i].p_vaddr + off))
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
firstaddr = phdr[i].p_vaddr + off;
Implement preloading for elf modules - get dependency info from PT_DYNAMIC's DT_NEEDED tags. - store MODINFOMD_DYNAMIC for the kernel's later use setenv kernelname when we have it Fix firstaddr/lastaddr calculation (duh! :-) Explicitly skip string table with section names in it.
1998-10-09 23:18:43 +00:00
if (lastaddr == 0 || lastaddr < (phdr[i].p_vaddr + off + phdr[i].p_memsz))
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
lastaddr = phdr[i].p_vaddr + off + phdr[i].p_memsz;
}
Only print kernel entry point during load. Drastically quieten down the verbose load progress messages. They were more useful for debugging than anything, but are beyond a joke when loading a few dozen modules. Simplify the ELF extended symbol table load format. Just take the main symbol table and the string table that corresponds. This is what we will be getting local symbols from. (needed for the alpha stack tracebacks). Use the (optional) full symbol tables in lookups. This means we have to furhter distinguish between symbols that can come from the dynamic linking table and the complete table. The alpha boot code now needs to be adapted as ddb/db_elf.c cannot use the simpler format. I have not implemented loading the extended symbol tables from the syscall interface yet, just for preloaded modules. I am not sure about the symbol resolution. I *think* it's possible that a local symbol can be found in preference to a global, depending on the search sequence and dependency tree.
1998-10-12 09:13:50 +00:00
lastaddr = roundup(lastaddr, sizeof(long));
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
First shot at loading elf symbols. Things are a bit strange because of the ..umm.. "wierd" way binutils lays out the file. The section headers are nearly at the end of the file and this is a problem when loading from a .gz file which can't seek backwards (or has a limited reverse seek, ~2K from memory). This is intended to be compatable with the ddb/db_elf.c code and the alpha/libalpha/elf_freebsd.c layout. I've studied these (which are NetBSD derived) but did it a bit differently. Naturally the process is similar since it's supposed to end up with the same result.
1998-10-02 08:04:56 +00:00
/*
* Now grab the symbol tables. This isn't easy if we're reading a
* .gz file. I think the rule is going to have to be that you must
* strip a file to remove symbols before gzipping it so that we do not
Only print kernel entry point during load. Drastically quieten down the verbose load progress messages. They were more useful for debugging than anything, but are beyond a joke when loading a few dozen modules. Simplify the ELF extended symbol table load format. Just take the main symbol table and the string table that corresponds. This is what we will be getting local symbols from. (needed for the alpha stack tracebacks). Use the (optional) full symbol tables in lookups. This means we have to furhter distinguish between symbols that can come from the dynamic linking table and the complete table. The alpha boot code now needs to be adapted as ddb/db_elf.c cannot use the simpler format. I have not implemented loading the extended symbol tables from the syscall interface yet, just for preloaded modules. I am not sure about the symbol resolution. I *think* it's possible that a local symbol can be found in preference to a global, depending on the search sequence and dependency tree.
1998-10-12 09:13:50 +00:00
* try to lseek() on it.
First shot at loading elf symbols. Things are a bit strange because of the ..umm.. "wierd" way binutils lays out the file. The section headers are nearly at the end of the file and this is a problem when loading from a .gz file which can't seek backwards (or has a limited reverse seek, ~2K from memory). This is intended to be compatable with the ddb/db_elf.c code and the alpha/libalpha/elf_freebsd.c layout. I've studied these (which are NetBSD derived) but did it a bit differently. Naturally the process is similar since it's supposed to end up with the same result.
1998-10-02 08:04:56 +00:00
*/
chunk = ehdr->e_shnum * ehdr->e_shentsize;
Make the ELF load messages cleaner.
1998-10-13 09:25:27 +00:00
if (chunk == 0 || ehdr->e_shoff == 0)
goto nosyms;
First shot at loading elf symbols. Things are a bit strange because of the ..umm.. "wierd" way binutils lays out the file. The section headers are nearly at the end of the file and this is a problem when loading from a .gz file which can't seek backwards (or has a limited reverse seek, ~2K from memory). This is intended to be compatable with the ddb/db_elf.c code and the alpha/libalpha/elf_freebsd.c layout. I've studied these (which are NetBSD derived) but did it a bit differently. Naturally the process is similar since it's supposed to end up with the same result.
1998-10-02 08:04:56 +00:00
shdr = malloc(chunk);
if (shdr == NULL)
goto nosyms;
Cleanup warnings. Most of these are signed/unsigned warnings, as well as some added const's.
2000-08-03 09:14:02 +00:00
if (lseek(ef->fd, (off_t)ehdr->e_shoff, SEEK_SET) == -1) {
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
printf("\nelf" __XSTRING(__ELF_WORD_SIZE) "_loadimage: cannot lseek() to section headers");
First shot at loading elf symbols. Things are a bit strange because of the ..umm.. "wierd" way binutils lays out the file. The section headers are nearly at the end of the file and this is a problem when loading from a .gz file which can't seek backwards (or has a limited reverse seek, ~2K from memory). This is intended to be compatable with the ddb/db_elf.c code and the alpha/libalpha/elf_freebsd.c layout. I've studied these (which are NetBSD derived) but did it a bit differently. Naturally the process is similar since it's supposed to end up with the same result.
1998-10-02 08:04:56 +00:00
goto nosyms;
}
Cleanup warnings. Most of these are signed/unsigned warnings, as well as some added const's.
2000-08-03 09:14:02 +00:00
result = read(ef->fd, shdr, chunk);
if (result < 0 || (size_t)result != chunk) {
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
printf("\nelf" __XSTRING(__ELF_WORD_SIZE) "_loadimage: read section headers failed");
First shot at loading elf symbols. Things are a bit strange because of the ..umm.. "wierd" way binutils lays out the file. The section headers are nearly at the end of the file and this is a problem when loading from a .gz file which can't seek backwards (or has a limited reverse seek, ~2K from memory). This is intended to be compatable with the ddb/db_elf.c code and the alpha/libalpha/elf_freebsd.c layout. I've studied these (which are NetBSD derived) but did it a bit differently. Naturally the process is similar since it's supposed to end up with the same result.
1998-10-02 08:04:56 +00:00
goto nosyms;
}
Only print kernel entry point during load. Drastically quieten down the verbose load progress messages. They were more useful for debugging than anything, but are beyond a joke when loading a few dozen modules. Simplify the ELF extended symbol table load format. Just take the main symbol table and the string table that corresponds. This is what we will be getting local symbols from. (needed for the alpha stack tracebacks). Use the (optional) full symbol tables in lookups. This means we have to furhter distinguish between symbols that can come from the dynamic linking table and the complete table. The alpha boot code now needs to be adapted as ddb/db_elf.c cannot use the simpler format. I have not implemented loading the extended symbol tables from the syscall interface yet, just for preloaded modules. I am not sure about the symbol resolution. I *think* it's possible that a local symbol can be found in preference to a global, depending on the search sequence and dependency tree.
1998-10-12 09:13:50 +00:00
symtabindex = -1;
symstrindex = -1;
First shot at loading elf symbols. Things are a bit strange because of the ..umm.. "wierd" way binutils lays out the file. The section headers are nearly at the end of the file and this is a problem when loading from a .gz file which can't seek backwards (or has a limited reverse seek, ~2K from memory). This is intended to be compatable with the ddb/db_elf.c code and the alpha/libalpha/elf_freebsd.c layout. I've studied these (which are NetBSD derived) but did it a bit differently. Naturally the process is similar since it's supposed to end up with the same result.
1998-10-02 08:04:56 +00:00
for (i = 0; i < ehdr->e_shnum; i++) {
Only print kernel entry point during load. Drastically quieten down the verbose load progress messages. They were more useful for debugging than anything, but are beyond a joke when loading a few dozen modules. Simplify the ELF extended symbol table load format. Just take the main symbol table and the string table that corresponds. This is what we will be getting local symbols from. (needed for the alpha stack tracebacks). Use the (optional) full symbol tables in lookups. This means we have to furhter distinguish between symbols that can come from the dynamic linking table and the complete table. The alpha boot code now needs to be adapted as ddb/db_elf.c cannot use the simpler format. I have not implemented loading the extended symbol tables from the syscall interface yet, just for preloaded modules. I am not sure about the symbol resolution. I *think* it's possible that a local symbol can be found in preference to a global, depending on the search sequence and dependency tree.
1998-10-12 09:13:50 +00:00
if (shdr[i].sh_type != SHT_SYMTAB)
Implement preloading for elf modules - get dependency info from PT_DYNAMIC's DT_NEEDED tags. - store MODINFOMD_DYNAMIC for the kernel's later use setenv kernelname when we have it Fix firstaddr/lastaddr calculation (duh! :-) Explicitly skip string table with section names in it.
1998-10-09 23:18:43 +00:00
continue;
First shot at loading elf symbols. Things are a bit strange because of the ..umm.. "wierd" way binutils lays out the file. The section headers are nearly at the end of the file and this is a problem when loading from a .gz file which can't seek backwards (or has a limited reverse seek, ~2K from memory). This is intended to be compatable with the ddb/db_elf.c code and the alpha/libalpha/elf_freebsd.c layout. I've studied these (which are NetBSD derived) but did it a bit differently. Naturally the process is similar since it's supposed to end up with the same result.
1998-10-02 08:04:56 +00:00
for (j = 0; j < ehdr->e_phnum; j++) {
if (phdr[j].p_type != PT_LOAD)
continue;
if (shdr[i].sh_offset >= phdr[j].p_offset &&
(shdr[i].sh_offset + shdr[i].sh_size <=
phdr[j].p_offset + phdr[j].p_filesz)) {
shdr[i].sh_offset = 0;
shdr[i].sh_size = 0;
break;
}
}
if (shdr[i].sh_offset == 0 || shdr[i].sh_size == 0)
continue; /* alread loaded in a PT_LOAD above */
Only print kernel entry point during load. Drastically quieten down the verbose load progress messages. They were more useful for debugging than anything, but are beyond a joke when loading a few dozen modules. Simplify the ELF extended symbol table load format. Just take the main symbol table and the string table that corresponds. This is what we will be getting local symbols from. (needed for the alpha stack tracebacks). Use the (optional) full symbol tables in lookups. This means we have to furhter distinguish between symbols that can come from the dynamic linking table and the complete table. The alpha boot code now needs to be adapted as ddb/db_elf.c cannot use the simpler format. I have not implemented loading the extended symbol tables from the syscall interface yet, just for preloaded modules. I am not sure about the symbol resolution. I *think* it's possible that a local symbol can be found in preference to a global, depending on the search sequence and dependency tree.
1998-10-12 09:13:50 +00:00
/* Save it for loading below */
symtabindex = i;
symstrindex = shdr[i].sh_link;
}
if (symtabindex < 0 || symstrindex < 0)
goto nosyms;
/* Ok, committed to a load. */
#ifndef ELF_VERBOSE
Make the ELF load messages cleaner.
1998-10-13 09:25:27 +00:00
printf("syms=[");
Only print kernel entry point during load. Drastically quieten down the verbose load progress messages. They were more useful for debugging than anything, but are beyond a joke when loading a few dozen modules. Simplify the ELF extended symbol table load format. Just take the main symbol table and the string table that corresponds. This is what we will be getting local symbols from. (needed for the alpha stack tracebacks). Use the (optional) full symbol tables in lookups. This means we have to furhter distinguish between symbols that can come from the dynamic linking table and the complete table. The alpha boot code now needs to be adapted as ddb/db_elf.c cannot use the simpler format. I have not implemented loading the extended symbol tables from the syscall interface yet, just for preloaded modules. I am not sure about the symbol resolution. I *think* it's possible that a local symbol can be found in preference to a global, depending on the search sequence and dependency tree.
1998-10-12 09:13:50 +00:00
#endif
ssym = lastaddr;
for (i = symtabindex; i >= 0; i = symstrindex) {
#ifdef ELF_VERBOSE
char *secname;
switch(shdr[i].sh_type) {
case SHT_SYMTAB: /* Symbol table */
secname = "symtab";
break;
case SHT_STRTAB: /* String table */
secname = "strtab";
break;
default:
secname = "WHOA!!";
break;
}
#endif
size = shdr[i].sh_size;
archsw.arch_copyin(&size, lastaddr, sizeof(size));
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
lastaddr += sizeof(size);
First shot at loading elf symbols. Things are a bit strange because of the ..umm.. "wierd" way binutils lays out the file. The section headers are nearly at the end of the file and this is a problem when loading from a .gz file which can't seek backwards (or has a limited reverse seek, ~2K from memory). This is intended to be compatable with the ddb/db_elf.c code and the alpha/libalpha/elf_freebsd.c layout. I've studied these (which are NetBSD derived) but did it a bit differently. Naturally the process is similar since it's supposed to end up with the same result.
1998-10-02 08:04:56 +00:00
Only print kernel entry point during load. Drastically quieten down the verbose load progress messages. They were more useful for debugging than anything, but are beyond a joke when loading a few dozen modules. Simplify the ELF extended symbol table load format. Just take the main symbol table and the string table that corresponds. This is what we will be getting local symbols from. (needed for the alpha stack tracebacks). Use the (optional) full symbol tables in lookups. This means we have to furhter distinguish between symbols that can come from the dynamic linking table and the complete table. The alpha boot code now needs to be adapted as ddb/db_elf.c cannot use the simpler format. I have not implemented loading the extended symbol tables from the syscall interface yet, just for preloaded modules. I am not sure about the symbol resolution. I *think* it's possible that a local symbol can be found in preference to a global, depending on the search sequence and dependency tree.
1998-10-12 09:13:50 +00:00
#ifdef ELF_VERBOSE
Don't forget a trailing \n when loading a kernel that has been stripped. (This might make ELF_VERBOSE look funny, but I'm tempted to delete that anyway)
1999-01-04 18:37:41 +00:00
printf("\n%s: 0x%lx@0x%lx -> 0x%lx-0x%lx", secname,
First shot at loading elf symbols. Things are a bit strange because of the ..umm.. "wierd" way binutils lays out the file. The section headers are nearly at the end of the file and this is a problem when loading from a .gz file which can't seek backwards (or has a limited reverse seek, ~2K from memory). This is intended to be compatable with the ddb/db_elf.c code and the alpha/libalpha/elf_freebsd.c layout. I've studied these (which are NetBSD derived) but did it a bit differently. Naturally the process is similar since it's supposed to end up with the same result.
1998-10-02 08:04:56 +00:00
shdr[i].sh_size, shdr[i].sh_offset,
lastaddr, lastaddr + shdr[i].sh_size);
Only print kernel entry point during load. Drastically quieten down the verbose load progress messages. They were more useful for debugging than anything, but are beyond a joke when loading a few dozen modules. Simplify the ELF extended symbol table load format. Just take the main symbol table and the string table that corresponds. This is what we will be getting local symbols from. (needed for the alpha stack tracebacks). Use the (optional) full symbol tables in lookups. This means we have to furhter distinguish between symbols that can come from the dynamic linking table and the complete table. The alpha boot code now needs to be adapted as ddb/db_elf.c cannot use the simpler format. I have not implemented loading the extended symbol tables from the syscall interface yet, just for preloaded modules. I am not sure about the symbol resolution. I *think* it's possible that a local symbol can be found in preference to a global, depending on the search sequence and dependency tree.
1998-10-12 09:13:50 +00:00
#else
Make the ELF load messages cleaner.
1998-10-13 09:25:27 +00:00
if (i == symstrindex)
printf("+");
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
printf("0x%lx+0x%lx", (long)sizeof(size), (long)size);
Only print kernel entry point during load. Drastically quieten down the verbose load progress messages. They were more useful for debugging than anything, but are beyond a joke when loading a few dozen modules. Simplify the ELF extended symbol table load format. Just take the main symbol table and the string table that corresponds. This is what we will be getting local symbols from. (needed for the alpha stack tracebacks). Use the (optional) full symbol tables in lookups. This means we have to furhter distinguish between symbols that can come from the dynamic linking table and the complete table. The alpha boot code now needs to be adapted as ddb/db_elf.c cannot use the simpler format. I have not implemented loading the extended symbol tables from the syscall interface yet, just for preloaded modules. I am not sure about the symbol resolution. I *think* it's possible that a local symbol can be found in preference to a global, depending on the search sequence and dependency tree.
1998-10-12 09:13:50 +00:00
#endif
Cleanup warnings. Most of these are signed/unsigned warnings, as well as some added const's.
2000-08-03 09:14:02 +00:00
if (lseek(ef->fd, (off_t)shdr[i].sh_offset, SEEK_SET) == -1) {
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
printf("\nelf" __XSTRING(__ELF_WORD_SIZE) "_loadimage: could not seek for symbols - skipped!");
Only print kernel entry point during load. Drastically quieten down the verbose load progress messages. They were more useful for debugging than anything, but are beyond a joke when loading a few dozen modules. Simplify the ELF extended symbol table load format. Just take the main symbol table and the string table that corresponds. This is what we will be getting local symbols from. (needed for the alpha stack tracebacks). Use the (optional) full symbol tables in lookups. This means we have to furhter distinguish between symbols that can come from the dynamic linking table and the complete table. The alpha boot code now needs to be adapted as ddb/db_elf.c cannot use the simpler format. I have not implemented loading the extended symbol tables from the syscall interface yet, just for preloaded modules. I am not sure about the symbol resolution. I *think* it's possible that a local symbol can be found in preference to a global, depending on the search sequence and dependency tree.
1998-10-12 09:13:50 +00:00
lastaddr = ssym;
ssym = 0;
goto nosyms;
First shot at loading elf symbols. Things are a bit strange because of the ..umm.. "wierd" way binutils lays out the file. The section headers are nearly at the end of the file and this is a problem when loading from a .gz file which can't seek backwards (or has a limited reverse seek, ~2K from memory). This is intended to be compatable with the ddb/db_elf.c code and the alpha/libalpha/elf_freebsd.c layout. I've studied these (which are NetBSD derived) but did it a bit differently. Naturally the process is similar since it's supposed to end up with the same result.
1998-10-02 08:04:56 +00:00
}
Cleanup warnings. Most of these are signed/unsigned warnings, as well as some added const's.
2000-08-03 09:14:02 +00:00
result = archsw.arch_readin(ef->fd, lastaddr, shdr[i].sh_size);
if (result < 0 || (size_t)result != shdr[i].sh_size) {
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
printf("\nelf" __XSTRING(__ELF_WORD_SIZE) "_loadimage: could not read symbols - skipped!");
Only print kernel entry point during load. Drastically quieten down the verbose load progress messages. They were more useful for debugging than anything, but are beyond a joke when loading a few dozen modules. Simplify the ELF extended symbol table load format. Just take the main symbol table and the string table that corresponds. This is what we will be getting local symbols from. (needed for the alpha stack tracebacks). Use the (optional) full symbol tables in lookups. This means we have to furhter distinguish between symbols that can come from the dynamic linking table and the complete table. The alpha boot code now needs to be adapted as ddb/db_elf.c cannot use the simpler format. I have not implemented loading the extended symbol tables from the syscall interface yet, just for preloaded modules. I am not sure about the symbol resolution. I *think* it's possible that a local symbol can be found in preference to a global, depending on the search sequence and dependency tree.
1998-10-12 09:13:50 +00:00
lastaddr = ssym;
ssym = 0;
goto nosyms;
First shot at loading elf symbols. Things are a bit strange because of the ..umm.. "wierd" way binutils lays out the file. The section headers are nearly at the end of the file and this is a problem when loading from a .gz file which can't seek backwards (or has a limited reverse seek, ~2K from memory). This is intended to be compatable with the ddb/db_elf.c code and the alpha/libalpha/elf_freebsd.c layout. I've studied these (which are NetBSD derived) but did it a bit differently. Naturally the process is similar since it's supposed to end up with the same result.
1998-10-02 08:04:56 +00:00
}
/* Reset offsets relative to ssym */
lastaddr += shdr[i].sh_size;
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
lastaddr = roundup(lastaddr, sizeof(size));
Only print kernel entry point during load. Drastically quieten down the verbose load progress messages. They were more useful for debugging than anything, but are beyond a joke when loading a few dozen modules. Simplify the ELF extended symbol table load format. Just take the main symbol table and the string table that corresponds. This is what we will be getting local symbols from. (needed for the alpha stack tracebacks). Use the (optional) full symbol tables in lookups. This means we have to furhter distinguish between symbols that can come from the dynamic linking table and the complete table. The alpha boot code now needs to be adapted as ddb/db_elf.c cannot use the simpler format. I have not implemented loading the extended symbol tables from the syscall interface yet, just for preloaded modules. I am not sure about the symbol resolution. I *think* it's possible that a local symbol can be found in preference to a global, depending on the search sequence and dependency tree.
1998-10-12 09:13:50 +00:00
if (i == symtabindex)
symtabindex = -1;
else if (i == symstrindex)
symstrindex = -1;
First shot at loading elf symbols. Things are a bit strange because of the ..umm.. "wierd" way binutils lays out the file. The section headers are nearly at the end of the file and this is a problem when loading from a .gz file which can't seek backwards (or has a limited reverse seek, ~2K from memory). This is intended to be compatable with the ddb/db_elf.c code and the alpha/libalpha/elf_freebsd.c layout. I've studied these (which are NetBSD derived) but did it a bit differently. Naturally the process is similar since it's supposed to end up with the same result.
1998-10-02 08:04:56 +00:00
}
esym = lastaddr;
Only print kernel entry point during load. Drastically quieten down the verbose load progress messages. They were more useful for debugging than anything, but are beyond a joke when loading a few dozen modules. Simplify the ELF extended symbol table load format. Just take the main symbol table and the string table that corresponds. This is what we will be getting local symbols from. (needed for the alpha stack tracebacks). Use the (optional) full symbol tables in lookups. This means we have to furhter distinguish between symbols that can come from the dynamic linking table and the complete table. The alpha boot code now needs to be adapted as ddb/db_elf.c cannot use the simpler format. I have not implemented loading the extended symbol tables from the syscall interface yet, just for preloaded modules. I am not sure about the symbol resolution. I *think* it's possible that a local symbol can be found in preference to a global, depending on the search sequence and dependency tree.
1998-10-12 09:13:50 +00:00
#ifndef ELF_VERBOSE
Don't forget a trailing \n when loading a kernel that has been stripped. (This might make ELF_VERBOSE look funny, but I'm tempted to delete that anyway)
1999-01-04 18:37:41 +00:00
printf("]");
Only print kernel entry point during load. Drastically quieten down the verbose load progress messages. They were more useful for debugging than anything, but are beyond a joke when loading a few dozen modules. Simplify the ELF extended symbol table load format. Just take the main symbol table and the string table that corresponds. This is what we will be getting local symbols from. (needed for the alpha stack tracebacks). Use the (optional) full symbol tables in lookups. This means we have to furhter distinguish between symbols that can come from the dynamic linking table and the complete table. The alpha boot code now needs to be adapted as ddb/db_elf.c cannot use the simpler format. I have not implemented loading the extended symbol tables from the syscall interface yet, just for preloaded modules. I am not sure about the symbol resolution. I *think* it's possible that a local symbol can be found in preference to a global, depending on the search sequence and dependency tree.
1998-10-12 09:13:50 +00:00
#endif
First shot at loading elf symbols. Things are a bit strange because of the ..umm.. "wierd" way binutils lays out the file. The section headers are nearly at the end of the file and this is a problem when loading from a .gz file which can't seek backwards (or has a limited reverse seek, ~2K from memory). This is intended to be compatable with the ddb/db_elf.c code and the alpha/libalpha/elf_freebsd.c layout. I've studied these (which are NetBSD derived) but did it a bit differently. Naturally the process is similar since it's supposed to end up with the same result.
1998-10-02 08:04:56 +00:00
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
file_addmetadata(fp, MODINFOMD_SSYM, sizeof(ssym), &ssym);
file_addmetadata(fp, MODINFOMD_ESYM, sizeof(esym), &esym);
First shot at loading elf symbols. Things are a bit strange because of the ..umm.. "wierd" way binutils lays out the file. The section headers are nearly at the end of the file and this is a problem when loading from a .gz file which can't seek backwards (or has a limited reverse seek, ~2K from memory). This is intended to be compatable with the ddb/db_elf.c code and the alpha/libalpha/elf_freebsd.c layout. I've studied these (which are NetBSD derived) but did it a bit differently. Naturally the process is similar since it's supposed to end up with the same result.
1998-10-02 08:04:56 +00:00
nosyms:
Don't forget a trailing \n when loading a kernel that has been stripped. (This might make ELF_VERBOSE look funny, but I'm tempted to delete that anyway)
1999-01-04 18:37:41 +00:00
printf("\n");
First shot at loading elf symbols. Things are a bit strange because of the ..umm.. "wierd" way binutils lays out the file. The section headers are nearly at the end of the file and this is a problem when loading from a .gz file which can't seek backwards (or has a limited reverse seek, ~2K from memory). This is intended to be compatable with the ddb/db_elf.c code and the alpha/libalpha/elf_freebsd.c layout. I've studied these (which are NetBSD derived) but did it a bit differently. Naturally the process is similar since it's supposed to end up with the same result.
1998-10-02 08:04:56 +00:00
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
ret = lastaddr - firstaddr;
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
fp->f_addr = firstaddr;
Implement preloading for elf modules - get dependency info from PT_DYNAMIC's DT_NEEDED tags. - store MODINFOMD_DYNAMIC for the kernel's later use setenv kernelname when we have it Fix firstaddr/lastaddr calculation (duh! :-) Explicitly skip string table with section names in it.
1998-10-09 23:18:43 +00:00
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
php = NULL;
Implement preloading for elf modules - get dependency info from PT_DYNAMIC's DT_NEEDED tags. - store MODINFOMD_DYNAMIC for the kernel's later use setenv kernelname when we have it Fix firstaddr/lastaddr calculation (duh! :-) Explicitly skip string table with section names in it.
1998-10-09 23:18:43 +00:00
for (i = 0; i < ehdr->e_phnum; i++) {
if (phdr[i].p_type == PT_DYNAMIC) {
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
php = phdr + i;
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
adp = php->p_vaddr;
file_addmetadata(fp, MODINFOMD_DYNAMIC, sizeof(adp), &adp);
Implement preloading for elf modules - get dependency info from PT_DYNAMIC's DT_NEEDED tags. - store MODINFOMD_DYNAMIC for the kernel's later use setenv kernelname when we have it Fix firstaddr/lastaddr calculation (duh! :-) Explicitly skip string table with section names in it.
1998-10-09 23:18:43 +00:00
break;
}
}
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
if (php == NULL) /* this is bad, we cannot get to symbols or _DYNAMIC */
Implement preloading for elf modules - get dependency info from PT_DYNAMIC's DT_NEEDED tags. - store MODINFOMD_DYNAMIC for the kernel's later use setenv kernelname when we have it Fix firstaddr/lastaddr calculation (duh! :-) Explicitly skip string table with section names in it.
1998-10-09 23:18:43 +00:00
goto out;
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
ndp = php->p_filesz / sizeof(Elf_Dyn);
if (ndp == 0)
goto out;
dp = malloc(php->p_filesz);
if (dp == NULL)
Implement preloading for elf modules - get dependency info from PT_DYNAMIC's DT_NEEDED tags. - store MODINFOMD_DYNAMIC for the kernel's later use setenv kernelname when we have it Fix firstaddr/lastaddr calculation (duh! :-) Explicitly skip string table with section names in it.
1998-10-09 23:18:43 +00:00
goto out;
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
archsw.arch_copyout(php->p_vaddr + off, dp, php->p_filesz);
ef->strsz = 0;
Implement preloading for elf modules - get dependency info from PT_DYNAMIC's DT_NEEDED tags. - store MODINFOMD_DYNAMIC for the kernel's later use setenv kernelname when we have it Fix firstaddr/lastaddr calculation (duh! :-) Explicitly skip string table with section names in it.
1998-10-09 23:18:43 +00:00
for (i = 0; i < ndp; i++) {
if (dp[i].d_tag == NULL)
break;
switch (dp[i].d_tag) {
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
case DT_HASH:
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
ef->hashtab = (Elf_Hashelt*)(uintptr_t)(dp[i].d_un.d_ptr + off);
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
break;
Implement preloading for elf modules - get dependency info from PT_DYNAMIC's DT_NEEDED tags. - store MODINFOMD_DYNAMIC for the kernel's later use setenv kernelname when we have it Fix firstaddr/lastaddr calculation (duh! :-) Explicitly skip string table with section names in it.
1998-10-09 23:18:43 +00:00
case DT_STRTAB:
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
ef->strtab = (char *)(uintptr_t)(dp[i].d_un.d_ptr + off);
Implement preloading for elf modules - get dependency info from PT_DYNAMIC's DT_NEEDED tags. - store MODINFOMD_DYNAMIC for the kernel's later use setenv kernelname when we have it Fix firstaddr/lastaddr calculation (duh! :-) Explicitly skip string table with section names in it.
1998-10-09 23:18:43 +00:00
break;
case DT_STRSZ:
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
ef->strsz = dp[i].d_un.d_val;
break;
case DT_SYMTAB:
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
ef->symtab = (Elf_Sym*)(uintptr_t)(dp[i].d_un.d_ptr + off);
Implement preloading for elf modules - get dependency info from PT_DYNAMIC's DT_NEEDED tags. - store MODINFOMD_DYNAMIC for the kernel's later use setenv kernelname when we have it Fix firstaddr/lastaddr calculation (duh! :-) Explicitly skip string table with section names in it.
1998-10-09 23:18:43 +00:00
break;
Fix module dependency (pre)loading on sparc64 by relocating the variables read from the raw kld files. Submitted by: Hartmut Brandt <brandt@fokus.gmd.de> PR: 46870 Tested on: alpha (obrien), i386, sparc64
2003-01-21 05:46:46 +00:00
case DT_RELA:
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
ef->rela = (Elf_Rela *)(uintptr_t)(dp[i].d_un.d_ptr + off);
Fix module dependency (pre)loading on sparc64 by relocating the variables read from the raw kld files. Submitted by: Hartmut Brandt <brandt@fokus.gmd.de> PR: 46870 Tested on: alpha (obrien), i386, sparc64
2003-01-21 05:46:46 +00:00
break;
case DT_RELASZ:
ef->relasz = dp[i].d_un.d_val;
break;
Implement preloading for elf modules - get dependency info from PT_DYNAMIC's DT_NEEDED tags. - store MODINFOMD_DYNAMIC for the kernel's later use setenv kernelname when we have it Fix firstaddr/lastaddr calculation (duh! :-) Explicitly skip string table with section names in it.
1998-10-09 23:18:43 +00:00
default:
break;
}
}
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
if (ef->hashtab == NULL || ef->symtab == NULL ||
ef->strtab == NULL || ef->strsz == 0)
goto out;
COPYOUT(ef->hashtab, &ef->nbuckets, sizeof(ef->nbuckets));
COPYOUT(ef->hashtab + 1, &ef->nchains, sizeof(ef->nchains));
ef->buckets = ef->hashtab + 2;
ef->chains = ef->buckets + ef->nbuckets;
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
if (__elfN(parse_modmetadata)(fp, ef) == 0)
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
goto out;
if (ef->kernel) /* kernel must not depend on anything */
Implement preloading for elf modules - get dependency info from PT_DYNAMIC's DT_NEEDED tags. - store MODINFOMD_DYNAMIC for the kernel's later use setenv kernelname when we have it Fix firstaddr/lastaddr calculation (duh! :-) Explicitly skip string table with section names in it.
1998-10-09 23:18:43 +00:00
goto out;
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
out:
Implement preloading for elf modules - get dependency info from PT_DYNAMIC's DT_NEEDED tags. - store MODINFOMD_DYNAMIC for the kernel's later use setenv kernelname when we have it Fix firstaddr/lastaddr calculation (duh! :-) Explicitly skip string table with section names in it.
1998-10-09 23:18:43 +00:00
if (dp)
free(dp);
if (shdr)
free(shdr);
ELF loader, part 1. It works with ELF kernels generated on the i386 so far, and should probably be able to be made to work for the alpha without too much trouble once it's connected up and my assumptions tested. I think (but have not tested) it will also load "old" ELF kernels that were not linked with DYNAMIC headers. The module glue is yet to come. (oh fun.. :-) It does not explicitly load symbols [yet]. The _DYNAMIC data contains a runtime symbol set that ddb can use via ddb/db_kld.c. It'll be missing some detail that stabs normally provides (eg: number of args to a function, line numbers, etc). On the other hand, those minimal symbols will always be available even on a stripped kernel. This is mostly stolen from load_aout.c with some ideas from alpha/libalpha/elf_freebsd.c.
1998-09-30 19:38:26 +00:00
return ret;
}
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
static char invalid_name[] = "bad";
Implement the long-awaited module->file cache database. A userland tool (kldxref(8)) keeps a cache of what modules and versions are inside what .ko files. I have tested this on both Alpha and i386. Submitted by: bp
2001-09-11 01:09:24 +00:00
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
char *
Fix some of the worst formatting bug (seperate commit)
2001-06-19 06:48:58 +00:00
fake_modname(const char *name)
{
Get rid of some constness warnings.
2001-06-24 12:08:47 +00:00
const char *sp, *ep;
char *fp;
Cleanup warnings. Most of these are signed/unsigned warnings, as well as some added const's.
2000-08-03 09:14:02 +00:00
size_t len;
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
sp = strrchr(name, '/');
if (sp)
sp++;
else
sp = name;
ep = strrchr(name, '.');
if (ep) {
if (ep == name) {
sp = invalid_name;
ep = invalid_name + sizeof(invalid_name) - 1;
}
} else
ep = name + strlen(name);
len = ep - sp;
Get rid of some constness warnings.
2001-06-24 12:08:47 +00:00
fp = malloc(len + 1);
if (fp == NULL)
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
return NULL;
Get rid of some constness warnings.
2001-06-24 12:08:47 +00:00
memcpy(fp, sp, len);
fp[len] = '\0';
return fp;
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
}
Fix lookup of module metadata on amd64 systems. While this is in common code, the non-trivial part is #ifdef'ed and only executes when loading amd64 kernels. The rest is trivial but needed for the the amd64 case. (Two variables changed from char ** to Elf_Addr). Approved by: re (amd64 "low-risk" stuff)
2003-05-12 05:48:09 +00:00
#if defined(__i386__) && __ELF_WORD_SIZE == 64
struct mod_metadata64 {
int md_version; /* structure version MDTV_* */
int md_type; /* type of entry MDT_* */
u_int64_t md_data; /* specific data */
u_int64_t md_cval; /* common string label */
};
#endif
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
int
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
__elfN(parse_modmetadata)(struct preloaded_file *fp, elf_file_t ef)
Fix some of the worst formatting bug (seperate commit)
2001-06-19 06:48:58 +00:00
{
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
struct mod_metadata md;
Fix lookup of module metadata on amd64 systems. While this is in common code, the non-trivial part is #ifdef'ed and only executes when loading amd64 kernels. The rest is trivial but needed for the the amd64 case. (Two variables changed from char ** to Elf_Addr). Approved by: re (amd64 "low-risk" stuff)
2003-05-12 05:48:09 +00:00
#if defined(__i386__) && __ELF_WORD_SIZE == 64
struct mod_metadata64 md64;
#endif
Implement the long-awaited module->file cache database. A userland tool (kldxref(8)) keeps a cache of what modules and versions are inside what .ko files. I have tested this on both Alpha and i386. Submitted by: bp
2001-09-11 01:09:24 +00:00
struct mod_depend *mdepend;
struct mod_version mver;
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
Elf_Sym sym;
Fix lookup of module metadata on amd64 systems. While this is in common code, the non-trivial part is #ifdef'ed and only executes when loading amd64 kernels. The rest is trivial but needed for the the amd64 case. (Two variables changed from char ** to Elf_Addr). Approved by: re (amd64 "low-risk" stuff)
2003-05-12 05:48:09 +00:00
char *s;
Implement the long-awaited module->file cache database. A userland tool (kldxref(8)) keeps a cache of what modules and versions are inside what .ko files. I have tested this on both Alpha and i386. Submitted by: bp
2001-09-11 01:09:24 +00:00
int modcnt, minfolen;
Fix lookup of module metadata on amd64 systems. While this is in common code, the non-trivial part is #ifdef'ed and only executes when loading amd64 kernels. The rest is trivial but needed for the the amd64 case. (Two variables changed from char ** to Elf_Addr). Approved by: re (amd64 "low-risk" stuff)
2003-05-12 05:48:09 +00:00
Elf_Addr v, p, p_stop;
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
if (__elfN(lookup_symbol)(fp, ef, "__start_set_modmetadata_set", &sym) != 0)
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
return ENOENT;
Fix lookup of module metadata on amd64 systems. While this is in common code, the non-trivial part is #ifdef'ed and only executes when loading amd64 kernels. The rest is trivial but needed for the the amd64 case. (Two variables changed from char ** to Elf_Addr). Approved by: re (amd64 "low-risk" stuff)
2003-05-12 05:48:09 +00:00
p = sym.st_value + ef->off;
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
if (__elfN(lookup_symbol)(fp, ef, "__stop_set_modmetadata_set", &sym) != 0)
Convert the elf loader to the new linker set layout for elf files. This should make dependencies at load time work like before. Oops. Noticed by: markm
2001-06-19 07:41:07 +00:00
return ENOENT;
Fix lookup of module metadata on amd64 systems. While this is in common code, the non-trivial part is #ifdef'ed and only executes when loading amd64 kernels. The rest is trivial but needed for the the amd64 case. (Two variables changed from char ** to Elf_Addr). Approved by: re (amd64 "low-risk" stuff)
2003-05-12 05:48:09 +00:00
p_stop = sym.st_value + ef->off;
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
modcnt = 0;
Convert the elf loader to the new linker set layout for elf files. This should make dependencies at load time work like before. Oops. Noticed by: markm
2001-06-19 07:41:07 +00:00
while (p < p_stop) {
Fix module dependency (pre)loading on sparc64 by relocating the variables read from the raw kld files. Submitted by: Hartmut Brandt <brandt@fokus.gmd.de> PR: 46870 Tested on: alpha (obrien), i386, sparc64
2003-01-21 05:46:46 +00:00
COPYOUT(p, &v, sizeof(v));
#ifdef __sparc64__
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
__elfN(reloc_ptr)(fp, ef, p, &v, sizeof(v));
Fix module dependency (pre)loading on sparc64 by relocating the variables read from the raw kld files. Submitted by: Hartmut Brandt <brandt@fokus.gmd.de> PR: 46870 Tested on: alpha (obrien), i386, sparc64
2003-01-21 05:46:46 +00:00
#else
v += ef->off;
#endif
Fix lookup of module metadata on amd64 systems. While this is in common code, the non-trivial part is #ifdef'ed and only executes when loading amd64 kernels. The rest is trivial but needed for the the amd64 case. (Two variables changed from char ** to Elf_Addr). Approved by: re (amd64 "low-risk" stuff)
2003-05-12 05:48:09 +00:00
#if defined(__i386__) && __ELF_WORD_SIZE == 64
COPYOUT(v, &md64, sizeof(md64));
md.md_version = md64.md_version;
md.md_type = md64.md_type;
md.md_cval = (const char *)(uintptr_t)(md64.md_cval + ef->off);
md.md_data = (void *)(uintptr_t)(md64.md_data + ef->off);
#else
Fix module dependency (pre)loading on sparc64 by relocating the variables read from the raw kld files. Submitted by: Hartmut Brandt <brandt@fokus.gmd.de> PR: 46870 Tested on: alpha (obrien), i386, sparc64
2003-01-21 05:46:46 +00:00
COPYOUT(v, &md, sizeof(md));
#ifdef __sparc64__
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
__elfN(reloc_ptr)(fp, ef, v, &md, sizeof(md));
Fix module dependency (pre)loading on sparc64 by relocating the variables read from the raw kld files. Submitted by: Hartmut Brandt <brandt@fokus.gmd.de> PR: 46870 Tested on: alpha (obrien), i386, sparc64
2003-01-21 05:46:46 +00:00
#else
md.md_cval += ef->off;
md.md_data += ef->off;
#endif
Fix lookup of module metadata on amd64 systems. While this is in common code, the non-trivial part is #ifdef'ed and only executes when loading amd64 kernels. The rest is trivial but needed for the the amd64 case. (Two variables changed from char ** to Elf_Addr). Approved by: re (amd64 "low-risk" stuff)
2003-05-12 05:48:09 +00:00
#endif
p += sizeof(Elf_Addr);
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
switch(md.md_type) {
case MDT_DEPEND:
if (ef->kernel) /* kernel must not depend on anything */
break;
Fix module dependency (pre)loading on sparc64 by relocating the variables read from the raw kld files. Submitted by: Hartmut Brandt <brandt@fokus.gmd.de> PR: 46870 Tested on: alpha (obrien), i386, sparc64
2003-01-21 05:46:46 +00:00
s = strdupout((vm_offset_t)md.md_cval);
Implement the long-awaited module->file cache database. A userland tool (kldxref(8)) keeps a cache of what modules and versions are inside what .ko files. I have tested this on both Alpha and i386. Submitted by: bp
2001-09-11 01:09:24 +00:00
minfolen = sizeof(*mdepend) + strlen(s) + 1;
mdepend = malloc(minfolen);
if (mdepend == NULL)
return ENOMEM;
Fix module dependency (pre)loading on sparc64 by relocating the variables read from the raw kld files. Submitted by: Hartmut Brandt <brandt@fokus.gmd.de> PR: 46870 Tested on: alpha (obrien), i386, sparc64
2003-01-21 05:46:46 +00:00
COPYOUT((vm_offset_t)md.md_data, mdepend, sizeof(*mdepend));
Implement the long-awaited module->file cache database. A userland tool (kldxref(8)) keeps a cache of what modules and versions are inside what .ko files. I have tested this on both Alpha and i386. Submitted by: bp
2001-09-11 01:09:24 +00:00
strcpy((char*)(mdepend + 1), s);
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
free(s);
Implement the long-awaited module->file cache database. A userland tool (kldxref(8)) keeps a cache of what modules and versions are inside what .ko files. I have tested this on both Alpha and i386. Submitted by: bp
2001-09-11 01:09:24 +00:00
file_addmetadata(fp, MODINFOMD_DEPLIST, minfolen, mdepend);
free(mdepend);
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
break;
case MDT_VERSION:
Fix module dependency (pre)loading on sparc64 by relocating the variables read from the raw kld files. Submitted by: Hartmut Brandt <brandt@fokus.gmd.de> PR: 46870 Tested on: alpha (obrien), i386, sparc64
2003-01-21 05:46:46 +00:00
s = strdupout((vm_offset_t)md.md_cval);
COPYOUT((vm_offset_t)md.md_data, &mver, sizeof(mver));
Implement the long-awaited module->file cache database. A userland tool (kldxref(8)) keeps a cache of what modules and versions are inside what .ko files. I have tested this on both Alpha and i386. Submitted by: bp
2001-09-11 01:09:24 +00:00
file_addmodule(fp, s, mver.mv_version, NULL);
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
free(s);
modcnt++;
break;
}
}
if (modcnt == 0) {
s = fake_modname(fp->f_name);
Implement the long-awaited module->file cache database. A userland tool (kldxref(8)) keeps a cache of what modules and versions are inside what .ko files. I have tested this on both Alpha and i386. Submitted by: bp
2001-09-11 01:09:24 +00:00
file_addmodule(fp, s, 1, NULL);
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
free(s);
}
return 0;
}
static unsigned long
elf_hash(const char *name)
{
const unsigned char *p = (const unsigned char *) name;
unsigned long h = 0;
unsigned long g;
while (*p != '\0') {
h = (h << 4) + *p++;
if ((g = h & 0xf0000000) != 0)
h ^= g >> 24;
h &= ~g;
}
return h;
}
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
static const char __elfN(bad_symtable)[] = "elf" __XSTRING(__ELF_WORD_SIZE) "_lookup_symbol: corrupt symbol table\n";
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
int
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
__elfN(lookup_symbol)(struct preloaded_file *fp, elf_file_t ef, const char* name,
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
Elf_Sym *symp)
{
Fix another unsigned long used to index the symbol table which should be Elf_Hashelt.
2002-04-09 00:05:46 +00:00
Elf_Hashelt symnum;
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
Elf_Sym sym;
char *strp;
unsigned long hash;
hash = elf_hash(name);
COPYOUT(&ef->buckets[hash % ef->nbuckets], &symnum, sizeof(symnum));
while (symnum != STN_UNDEF) {
if (symnum >= ef->nchains) {
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
printf(__elfN(bad_symtable));
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
return ENOENT;
}
COPYOUT(ef->symtab + symnum, &sym, sizeof(sym));
if (sym.st_name == 0) {
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
printf(__elfN(bad_symtable));
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
return ENOENT;
}
strp = strdupout((vm_offset_t)(ef->strtab + sym.st_name));
if (strcmp(name, strp) == 0) {
free(strp);
if (sym.st_shndx != SHN_UNDEF ||
(sym.st_value != 0 &&
ELF_ST_TYPE(sym.st_info) == STT_FUNC)) {
*symp = sym;
return 0;
}
return ENOENT;
}
free(strp);
COPYOUT(&ef->chains[symnum], &symnum, sizeof(symnum));
}
return ENOENT;
}
Fix module dependency (pre)loading on sparc64 by relocating the variables read from the raw kld files. Submitted by: Hartmut Brandt <brandt@fokus.gmd.de> PR: 46870 Tested on: alpha (obrien), i386, sparc64
2003-01-21 05:46:46 +00:00
#ifdef __sparc__
/*
* Apply any intra-module relocations to the value. *p is the load address
* of the value and val/len is the value to be modified. This does NOT modify
* the image in-place, because this is done by kern_linker later on.
*/
static void
Enable the i386 loader to load and run an amd64 kernel. If this puts things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
2003-05-01 03:56:30 +00:00
__elfN(reloc_ptr)(struct preloaded_file *mp, elf_file_t ef,
Fix module dependency (pre)loading on sparc64 by relocating the variables read from the raw kld files. Submitted by: Hartmut Brandt <brandt@fokus.gmd.de> PR: 46870 Tested on: alpha (obrien), i386, sparc64
2003-01-21 05:46:46 +00:00
void *p, void *val, size_t len)
{
Elf_Addr off = (Elf_Addr)p - ef->off, word;
size_t n;
Elf_Rela r;
for (n = 0; n < ef->relasz / sizeof(r); n++) {
COPYOUT(ef->rela + n, &r, sizeof(r));
if (r.r_offset >= off && r.r_offset < off + len &&
ELF_R_TYPE(r.r_info) == R_SPARC_RELATIVE) {
word = ef->off + r.r_addend;
bcopy(&word, (char *)val + (r.r_offset - off),
sizeof(word));
}
}
}
#endif
Reference in New Issue Copy Permalink