(link) address and the physical (load) address. Ideally, the mapping
between link and load addresses should be abstracted by the copyin(),
copyout() and readin() functions, so that we don't have to add kluges
in __elfN(loadimage)(). Then, we could also have paged virtual memory
for the kernel. This can be important under EFI, where you need to
allocate physical memory form the firmware if you want to work in all
scenarios.
to get the physical address doesn't work for all values of KVA_PAGES,
while masking 8 MSBs works for all values of KVA_PAGES that are
multiple of 4 for non-PAE and 8 for PAE. (This leaves us limited
with 12MB for non-PAE kernels and 14MB for PAE kernels.)
To get things right, we'd need to subtract the KERNBASE from the
virtual address (but KERNBASE is not easy to figure out from here),
or have physical addresses set properly in the ELF headers.
Discussed with: jhb
are no longer limited to a virtual address space of 16 megabytes,
only mask high two bits of a virtual address. This allows to load
larger kernels (up to 1 gigabyte). Not masking addresses at all
was a bad idea on machines with less than >3G of memory -- kernels
are linked at 0xc0xxxxxx, and that would attempt to load a kernel
at above 3G. By masking only two highest bits we stay within the
safe limits while still allowing to boot larger kernels.
(This is a safer reimplmentation of sys/boot/i386/boot2/boot.2.c
rev. 1.71.)
Prodded by: jhb
Tested by: nyan (pc98)
means:
o Remove Elf64_Quarter,
o Redefine Elf64_Half to be 16-bit,
o Redefine Elf64_Word to be 32-bit,
o Add Elf64_Xword and Elf64_Sxword for 64-bit entities,
o Use Elf_Size in MI code to abstract the difference between
Elf32_Word and Elf64_Word.
o Add Elf_Ssize as the signed counterpart of Elf_Size.
MFC after: 2 weeks
better relocation support for the amd64 and i386 platforms. This
should not result in any change in functionality, but moves a step
towards supporting the relocatable object file modules on amd64.
The same hack/trick as load_elf*.c uses is used here to simultaneously
support both elf32 and elf64 on amd64 and i386.
common code, the non-trivial part is #ifdef'ed and only executes when
loading amd64 kernels. The rest is trivial but needed for the the amd64
case. (Two variables changed from char ** to Elf_Addr).
Approved by: re (amd64 "low-risk" stuff)
things over floppy size limits, I can exclude it for release builds or
something like that. Most of the changes are to get the load_elf.c file
into a seperate elf32_ or elf64_ namespace so that you can have two
ELF loaders present at once. Note that for 64 bit kernels, it actually
starts up the kernel already in 64 bit mode with paging enabled. This
is really easy because we have a known minimum feature set.
Of note is that for amd64, we have to pass in the bios int 15 0xe821
memory map because once in long mode, you absolutely cannot make VM86
calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader
metadata startup, just like sparc64 and powerpc. Much of the
infrastructure to support this was adapted from sparc64.
Move the remaining bits of <sys/diskslice.h> to <i386/include/bootinfo.h>
Move i386/pc98 specific bits from <sys/reboot.h> to
<i386/include/bootinfo.h> as well.
Adjust includes in sys/boot accordingly.
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.
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.
- 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.
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.
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.
