summaryrefslogtreecommitdiffstats
path: root/sys/conf/ldscript.amd64
Commit message (Collapse)AuthorAgeFilesLines
* The new binutils has correctly redefined MAXPAGESIZE on amd64 as 0x200000alc2011-03-281-1/+2
| | | | | | | | | | | | | instead of 0x100000. As a side effect, an amd64 kernel now loads at physical address 0x200000 instead of 0x100000. This is probably for the best because it avoids the use of a 2MB page mapping for the first 1MB of the kernel that also spans the fixed MTRRs. However, getmemsize() still thinks that the kernel loads at 0x100000, and so the physical memory between 0x100000 and 0x200000 is lost. Fix this problem by replacing the hard-wired constant in getmemsize() by a symbol "kernphys" that is defined by the linker script. In collaboration with: kib
* Sync sys/conf/ldscript.amd64 with the upstream version, preservingdim2010-11-041-35/+81
| | | | | FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
* Binutils commit 0c845abb5a0083c6deebc75975608237015badba increaseddim2010-11-041-2/+3
| | | | | | | | | | | | | | | ELF_MAXPAGESIZE for amd64 from 0x00100000 to 0x00200000. This caused the kernel to be incorrectly linked, using the existing linker script, resulting in a virtual address of 0xffffffff80000000 for the LOAD program header. The boot loader will load such a kernel at a real address of 0x00000000, which either causes protection faults in btx, crashes the machine, or (in case of a VMware guest) even makes it power down. :) Fix this by partially synchronizing the amd64 linker script with binutils own updated version, in particular replacing a hardcoded value of 0x00100000 by CONSTANT(MAXPAGESIZE).
* Use new output format 'elf64-x86-64-freebsd' instead of 'elf64-x86-64',dim2010-11-011-1/+1
| | | | and similarly 'elf64-sparc-freebsd' instead of 'elf64-sparc'.
* Provide the _start_ctors and _stop_ctors symbols. As on i386, the addressestjr2004-05-291-0/+4
| | | | of these are the start and end of the .ctors section.
* Sync up with the files in the hammer branch in the p4 tree to get basicpeter2003-05-011-81/+117
| | | | AMD64 support. There is still more to add.
* Add two symbols start_ctors and stop_ctors to allow us to find thephk2003-01-061-0/+4
| | | | .ctors section so we can call the constructors.
* Use the new freebsd output format from Binutils 2.13.1.obrien2002-10-111-1/+1
|
* Remove hard coded magic load address. Now to change the load address,peter2001-09-181-1/+1
| | | | | we just have to change the pmap.h constants and ld will automatically adapt based on the "kernbase" symbol.
* Add $FreeBSD$peter2000-01-111-0/+1
| | | | | Make the alpha linker script more like the i386 version - delete the /usr/local and egcs directories
* Remove a rather bogus search path reference..peter1999-06-031-1/+1
|
* Increased kernel virtual address space to 1GB. NOTE: You MUST have fixeddg1999-03-111-1/+1
| | | | | | | | bootblocks in order to boot the kernel after this! Also note that this change breaks BSDI BSD/OS compatibility. Also increased default NKPT to 17 so that FreeBSD can boot on machines with >=2GB of RAM. Booting on machines with exactly 4GB requires other patches, not included.
* Make the ELF kernel build produce a dynamic executable (!). This enablespeter1998-09-301-0/+128
the in-kernel linker to access the _DYNAMIC data for doing loadable elf modules. The alpha kernel is already done this way, I've borrowed some of the hacks from there. This is primarily aimed at the 3-stage boot process which is intended to be able to do pre-loading of kernel modules. Note that the entry point isn't 0xf0100000 any more, it'll be a little further on - but this value is stored in the headers. I don't think this will be a problem, but I'm sure somebody will tell me if it is. :-) I'm not sure if btxboot is going to like this, it doesn't do proper ELF header checking and assumes that there are exactly two program header entries and that they are both PT_LOAD entries - a bad assumption.
OpenPOWER on IntegriCloud