summaryrefslogtreecommitdiffstats
path: root/sys/conf/ldscript.ia64
Commit message (Collapse)AuthorAgeFilesLines
* Have the linker provide btext. It's used for profiling.marcel2004-08-251-0/+1
|
* Fix the following error:marcel2004-06-201-0/+2
| | | | | | | | | | | | | | ld: locore.o: non-pic code with imm relocation against dynamic symbol `__gp' With binutils 2.15, ld(1) defines the implicit/automatic symbol __gp as a dynamic symbol and thus will now complain when used in a non-PIC fashion (the immediate relocation used to set the GP register). Resolve this by defining __gp in the linker script. Make sure __gp is aligned on a 16-byte boundary. Note: the 0x200000 magic offset is due to having a 22-bit GP-relative relocation. The GOT will be accessed with negative offsets from GP.
* Load the kernel at a 64M instead of 5M. The advantage of this is thatmarcel2003-09-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | we can switch to 64M-sized identity mappings and not having to map the first 64M. This is especially important because the first 1M contains the VGA frame buffer and is otherwise a legacy memory range. Best to make as little assumptions about it as possible. Switching to 64M-sized mappings is important to avoid creating overlapping translations, which have the side-effect of triggering machine checks. This is currently what's preventing us to boot on an Intel Tiger 4. Note that since we currently use 256M-sized identity mappings, we would reduce the size of the mappings and consequently increase the TLB pressure. The performance implications of this are minimal if measurable at all because identify mappings are not our primary means for memory management. Also note that there's no guarantee that physical memory exists at 64M. Then again, we didn't had the guarantee when we were loading at 5M. We'll deal with this when it's a problem. Discussed with: arun@
* Sync the linker script with the one used by default for userland. Sincemarcel2003-05-161-76/+82
| | | | | | | ia64 only uses relocations with addend, remove the sections specific to non-addend relocations (.rel.*). Also remove C++ specific sections. Approved by: re@ (blanket)
* Back out rev 1.7 -- I'm not sure we're ready for it and I can't test it.obrien2002-12-051-1/+1
| | | | | Marcel will find out RSN if it is needed and I'll let him fix this up if need be.
* Our binary output format is now "elf64-ia64-little-freebsd".obrien2002-12-051-1/+1
|
* Remove the _ia64_unwind_start and _ia64_unwind_end symbols. We nowmarcel2002-10-191-2/+0
| | | | find the unwind table through the ELF program headers.
* Cover the ELF headers with the text segment so that they get loadedmarcel2002-10-181-1/+1
| | | | | | into memory. This brings us in line with the other architectures and more easily allows us to do machine dependent processing on the ELF file (such as scanning for unwind information).
* Have the linker collect and combine all unwind_info and unwindmarcel2002-10-121-2/+2
| | | | | sections so that the resulting load module has a single unwind table. This matches the behaviour in userland.
* Put symbols at the start and end of the unwind section so that we candfr2001-10-291-0/+4
| | | | find it at runtime.
* Change the kernel layout to match Linux/ia64 more closely. This preventsdfr2001-03-091-8/+11
| | | | | the Linux loader from corrupting our text section when it attempts to write out boot options.
* This is the first snapshot of the FreeBSD/ia64 kernel. This kernel willdfr2000-09-291-0/+134
not work on any real hardware (or fully work on any simulator). Much more needs to happen before this is actually functional but its nice to see the FreeBSD copyright message appear in the ia64 simulator.
OpenPOWER on IntegriCloud