arch/x86/purgatory/setup-x86_64.S
Source file repositories/reference/linux-study-clean/arch/x86/purgatory/setup-x86_64.S
File Facts
- System
- Linux kernel
- Corpus path
arch/x86/purgatory/setup-x86_64.S- Extension
.S- Size
- 1198 bytes
- Lines
- 60
- Domain
- Architecture Layer
- Bucket
- arch/x86
- Inferred role
- Architecture Layer: arch/x86
- Status
- atlas-only
Why This File Exists
CPU and platform-specific kernel glue: boot entry, traps, syscall entry, interrupts, page tables, context switch, and low-level barriers.
- CPU and platform-specific kernel glue: boot entry, traps, syscall entry, interrupts, page tables, context switch, and low-level barriers.
Dependency Surface
linux/linkage.hasm/purgatory.h
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
#include <linux/linkage.h>
#include <asm/purgatory.h>
.text
.balign 16
.code64
SYM_CODE_START(purgatory_start)
/* Load a gdt so I know what the segment registers are */
lgdt gdt(%rip)
/* load the data segments */
movl $0x18, %eax /* data segment */
movl %eax, %ds
movl %eax, %es
movl %eax, %ss
movl %eax, %fs
movl %eax, %gs
/* Setup a stack */
leaq lstack_end(%rip), %rsp
/* Call the C code */
call purgatory
jmp entry64
SYM_CODE_END(purgatory_start)
.section ".rodata"
.balign 16
SYM_DATA_START_LOCAL(gdt)
/* 0x00 unusable segment
* 0x08 unused
* so use them as the gdt ptr
*/
.word gdt_end - gdt - 1
.quad gdt
.word 0, 0, 0
/* 0x10 4GB flat code segment */
.word 0xFFFF, 0x0000, 0x9A00, 0x00AF
/* 0x18 4GB flat data segment */
.word 0xFFFF, 0x0000, 0x9200, 0x00CF
SYM_DATA_END_LABEL(gdt, SYM_L_LOCAL, gdt_end)
.bss
.balign 4096
SYM_DATA_START_LOCAL(lstack)
.skip 4096
SYM_DATA_END_LABEL(lstack, SYM_L_LOCAL, lstack_end)
Annotation
- Immediate include surface: `linux/linkage.h`, `asm/purgatory.h`.
- Atlas domain: Architecture Layer / arch/x86.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.