1 files changed, 62 insertions, 0 deletions
diff --git a/linker.ld b/linker.ld
new file mode 100644
index 0000000..87fb6c4
--- /dev/null
+++ b/linker.ld
@@ -0,0 +1,62 @@
+/* The bootloader will look at this image and start execution at the symbol
+   designated as the entry point. */
+ENTRY(bootstrap)
+ 
+/* Tell where the various sections of the object files will be put in the final
+   kernel image. */
+SECTIONS
+{
+	/* It used to be universally recommended to use 1MiB as a start offset,
+	   as it was effectively guaranteed to be available under BIOS systems.
+	   However, UEFI has made things more complicated, and experimental data
+	   strongly suggests that 2M is a safer place to load. In 2016, a new
+	   feature was introduced to the multiboot2 spec to inform bootloaders
+	   that a kernel can be loaded anywhere within a range of addresses and
+	   will be able to  relocations to itself to run from such a loader-selected
+	   address, in order to give the loader freedom in selecting a span of
+	   memory which is verified to be available by the firmware, in order to
+	   work around this issue. This  does not use that feature, so 2M was
+	   chosen as a safer option than the traditional 1M. */
+	. = 2M;
+
+	.bootstrap BLOCK(4K) : ALIGN(4K)
+	{
+		*(.multiboot)
+		*(.bootstrap)
+	}
+
+	/* First put the multiboot header, as it is required to be put very early
+	   early in the image or the bootloader won't recognize the file format.
+	   Next we'll put the .text section. */
+	.text BLOCK(4K) : ALIGN(4K)
+	{
+		*(.text)
+	}
+
+	/* Read-only data. */
+	.rodata BLOCK(4K) : ALIGN(4K)
+	{
+		*(.rodata)
+	}
+
+	/* Read-write data (initialized) */
+	.data BLOCK(4K) : ALIGN(4K)
+	{
+		*(.data)
+	}
+
+	/* Read-write data (uninitialized) and stack */
+	.bss BLOCK(4K) : ALIGN(4K)
+	{
+		*(COMMON)
+		*(.bss)
+	}
+
+	.end BLOCK(4K) : ALIGN(4K)
+	{
+		*(.end)
+	}
+ 
+	/* The compiler may produce other sections, by default it will put them in
+	   a segment with the same name. Simply add stuff here as needed. */
+}