| 2e136f9a | 01-Nov-2015 |
Antonio Huete Jimenez <tuxillo@quantumachine.net> |
vkernel - Override max-page-size for ld.*
- Move max-page-size setting to the vkernel-specific SYSTEM_LD as it
was probably intended in ed9f17e. This overrides whatever the default
is in ld.bfd
vkernel - Override max-page-size for ld.*
- Move max-page-size setting to the vkernel-specific SYSTEM_LD as it
was probably intended in ed9f17e. This overrides whatever the default
is in ld.bfd or ld.gold.
show more ...
|
| e19c755c | 23-Feb-2012 |
John Marino <draco@marino.st> |
kern build: Tweak ldscripts for gold linker
The gold linker v2.21 was able to link a working kernel although its
modules were unloadable. The gold linker v2.22 could build loadable
modules, but the
kern build: Tweak ldscripts for gold linker
The gold linker v2.21 was able to link a working kernel although its
modules were unloadable. The gold linker v2.22 could build loadable
modules, but the kernel wouldn't boot! It's not clear why the modules
started to work -- my guess is that the ancient ldscripts used during
the 2.21 trial were the culprit.
The gold linker changed its ELF program header handling defaults for
version 2.22, and this resulted in an extra LOAD segment reserved only
for the program headers. The DragonFly loader wasn't expecting that
and instantly rebooted when trying to load a gold kernel.
The solution was to add a PHDRS section to the ldscripts to specify
exactly the section to segment mapping, and prevent gold from putting
the elf headers in their own load segment. Now gold matches gnu ld
linker in having only two LOAD segments, text and data.
As a curiousity, gold sets the LOAD segment alignment value at 0x1000
for both i386 and x86_64, where gnu ld sets the segment alignment at
0x1000 for i386 and 0x200000 for x86_64. This seems to have no impact
on the loading of the kernel.
show more ...
|