d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
3c0efe5da1
freebsd-dev/sys/boot/common/load_elf.c

517 lines
13 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.
*
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
* $Id: load_elf.c,v 1.8 1998/10/16 03:04:15 peter Exp $
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>
#include <sys/reboot.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>
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/bootinfo.h>
#include <machine/elf.h>
#include <stand.h>
#define FREEBSD_ELF
#include <link.h>
#include "bootstrap.h"
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
static int elf_loadimage(struct loaded_module *mp, int fd, vm_offset_t loadaddr, Elf_Ehdr *ehdr, int kernel, caddr_t firstpage, int firstlen);
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
char *elf_kerneltype = "elf kernel";
char *elf_moduletype = "elf module";
/*
* 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
elf_loadmodule(char *filename, vm_offset_t dest, struct loaded_module **result)
{
struct loaded_module *mp, *kmp;
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_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
int fd;
int err, kernel;
u_int 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
char *s;
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
caddr_t firstpage;
int firstlen;
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
mp = NULL;
/*
* Open the image, read and validate the ELF header
*/
if (filename == NULL) /* can't handle nameless */
return(EFTYPE);
if ((fd = open(filename, O_RDONLY)) == -1)
return(errno);
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
firstpage = malloc(PAGE_SIZE);
if (firstpage == NULL)
return(ENOMEM);
firstlen = read(fd, firstpage, PAGE_SIZE);
if (firstlen <= sizeof(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;
}
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
ehdr = (Elf_Ehdr *)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.
*/
kmp = mod_findmodule(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 */
if (kmp == NULL) {
printf("elf_loadmodule: can't load module before kernel\n");
err = EPERM;
goto oerr;
}
if (strcmp(elf_kerneltype, kmp->m_type)) {
printf("elf_loadmodule: can't load module with kernel type '%s'\n", kmp->m_type);
err = EPERM;
goto oerr;
}
/* Looks OK, got ahead */
kernel = 0;
/* 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 */
if (kmp != NULL) {
printf("elf_loadmodule: kernel already loaded\n");
err = EPERM;
goto oerr;
}
/*
* Calculate destination address based on kernel entrypoint
*/
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
dest = (vm_offset_t) 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) {
printf("elf_loadmodule: not a kernel (maybe static binary?)\n");
err = EPERM;
goto oerr;
}
kernel = 1;
} else {
err = EFTYPE;
goto oerr;
}
/*
* Ok, we think we should handle this.
*/
mp = mod_allocmodule();
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 (mp == NULL) {
printf("elf_loadmodule: cannot allocate module info\n");
err = EPERM;
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
if (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);
s = strrchr(filename, '/');
if (s)
mp->m_name = strdup(s + 1);
else
mp->m_name = strdup(filename);
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
mp->m_type = strdup(kernel ? elf_kerneltype : elf_moduletype);
Make the ELF load messages cleaner.
1998-10-13 09:25:27 +00:00
#ifdef ELF_VERBOSE
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 (kernel)
printf("%s entry at %p\n", filename, (void *) 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
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
mp->m_size = elf_loadimage(mp, fd, dest, ehdr, kernel, firstpage, firstlen);
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 (mp->m_size == 0 || mp->m_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 */
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
mod_addmetadata(mp, 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 */
*result = (struct loaded_module *)mp;
err = 0;
goto out;
ioerr:
err = EIO;
oerr:
mod_discard(mp);
out:
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 (firstpage)
free(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
close(fd);
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
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_loadimage(struct loaded_module *mp, int fd, vm_offset_t off,
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_Ehdr *ehdr, int kernel, caddr_t firstpage, int firstlen)
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
int i, j;
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_Phdr *phdr;
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;
vm_offset_t dest;
vm_offset_t 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;
int ndp;
int deplen;
char *depdata;
char *s;
int len;
char *strtab;
size_t strsz;
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;
long size;
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
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;
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 (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__
off = 0x10000000; /* -0xf0000000 - i386 relocates after locore */
#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
}
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 ((ehdr->e_phoff + ehdr->e_phnum * sizeof(*phdr)) > firstlen) {
printf("elf_loadimage: program header not within first page\n");
goto out;
}
phdr = (Elf_Phdr *)(firstpage + ehdr->e_phoff);
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;
if (firstlen > phdr[i].p_offset) {
fpcopy = firstlen - phdr[i].p_offset;
archsw.arch_copyin(firstpage + phdr[i].p_offset,
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) {
if (lseek(fd, phdr[i].p_offset + fpcopy, SEEK_SET) == -1) {
printf("\nelf_loadexec: cannot seek\n");
goto out;
}
if (archsw.arch_readin(fd, phdr[i].p_vaddr + off + fpcopy,
phdr[i].p_filesz - fpcopy) != phdr[i].p_filesz - fpcopy) {
printf("\nelf_loadexec: archsw.readin failed\n");
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);
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;
if (lseek(fd, ehdr->e_shoff, SEEK_SET) == -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
printf("\nelf_loadimage: cannot lseek() to section headers\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
goto nosyms;
}
if (read(fd, shdr, chunk) != chunk) {
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
printf("\nelf_loadimage: read section headers failed\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
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));
lastaddr += sizeof(long);
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
Change some printfs so that ELF_VERBOSE prints meaningful values on the alpha.
1998-10-15 21:56:47 +00:00
printf("%s: 0x%lx@0x%lx -> 0x%lx-0x%lx\n", 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("+");
"fix" the gzipped kernel load problem by having the loader check that it can seek back to the first PT_LOAD and doing a close/reopen if it cannot. This is because the first PT_LOAD section includes the ELF headers. This fixes gzipped kernels on the i386, it should solve mike's problem for the Alpha.
1998-10-16 03:04:15 +00:00
printf("0x%lx+0x%lx", (long)sizeof(size), 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
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
if (lseek(fd, shdr[i].sh_offset, SEEK_SET) == -1) {
printf("\nelf_loadimage: could not seek for symbols - skipped!\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
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
}
if (archsw.arch_readin(fd, lastaddr, shdr[i].sh_size) !=
shdr[i].sh_size) {
printf("\nelf_loadimage: could not read symbols - skipped!\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
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;
lastaddr = roundup(lastaddr, sizeof(long));
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
printf("]\n");
#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
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
mod_addmetadata(mp, MODINFOMD_SSYM, sizeof(ssym), &ssym);
mod_addmetadata(mp, 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:
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;
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
mp->m_addr = firstaddr;
for (i = 0; i < ehdr->e_phnum; i++) {
if (phdr[i].p_type == PT_DYNAMIC) {
dp = (Elf_Dyn *)(phdr[i].p_vaddr);
mod_addmetadata(mp, MODINFOMD_DYNAMIC, sizeof(dp), &dp);
dp = NULL;
break;
}
}
if (kernel) /* kernel must not depend on anything */
goto out;
ndp = 0;
for (i = 0; i < ehdr->e_phnum; i++) {
if (phdr[i].p_type == PT_DYNAMIC) {
ndp = phdr[i].p_filesz / sizeof(Elf_Dyn);
dp = malloc(phdr[i].p_filesz);
archsw.arch_copyout(phdr[i].p_vaddr + off, dp, phdr[i].p_filesz);
}
}
if (dp == NULL || ndp == 0)
goto out;
strtab = NULL;
strsz = 0;
deplen = 0;
for (i = 0; i < ndp; i++) {
if (dp[i].d_tag == NULL)
break;
switch (dp[i].d_tag) {
case DT_STRTAB:
strtab = (char *)(dp[i].d_un.d_ptr + off);
break;
case DT_STRSZ:
strsz = dp[i].d_un.d_val;
break;
default:
break;
}
}
if (strtab == NULL || strsz == 0)
goto out;
deplen = 0;
for (i = 0; i < ndp; i++) {
if (dp[i].d_tag == NULL)
break;
switch (dp[i].d_tag) {
case DT_NEEDED: /* count size for dependency list */
j = dp[i].d_un.d_ptr;
if (j < 1 || j > (strsz - 2))
continue; /* bad symbol name index */
deplen += strlenout((vm_offset_t)&strtab[j]) + 1;
break;
default:
break;
}
}
if (deplen > 0) {
depdata = malloc(deplen);
if (depdata == NULL)
goto out;
s = depdata;
for (i = 0; i < ndp; i++) {
if (dp[i].d_tag == NULL)
break;
switch (dp[i].d_tag) {
case DT_NEEDED: /* dependency list */
j = dp[i].d_un.d_ptr;
len = strlenout((vm_offset_t)&strtab[j]) + 1;
archsw.arch_copyout((vm_offset_t)&strtab[j], s, len);
s += len;
break;
default:
break;
}
}
if ((s - depdata) > 0)
mod_addmetadata(mp, MODINFOMD_DEPLIST, s - depdata, depdata);
free(depdata);
}
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;
}
Reference in New Issue Copy Permalink