Fix ld output with recent versions of GCC and binutils
Recent versions of GCC and binutils produce programs that make use of
"Secure COde Partitioning (SCOP)" as indicated by ld's separate-code flag.
SCOP adds an additional ELF segment that bears read, but not execute,
permissions, and Pintos is unable to load programs laid out in this way.
For instance, the version of ld on Fedora 31+ seems to break Pintos'
program loading by generating ELFs with the following layout:
$ readelf -l halt
Elf file type is EXEC (Executable file)
Entry point 0x80480cb
There are 4 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x08048000 0x08047000 0x000b4 0x000b4 R 0x1000
LOAD 0x0000c0 0x080480c0 0x080480c0 0x02699 0x02699 R E 0x1000
LOAD 0x00275c 0x0804b75c 0x0804b75c 0x00018 0x00019 RW 0x1000
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10
Section to Segment mapping:
Segment Sections...
00
01 .text .rodata .rodata.str1.4 .rodata.str1.1
02 .data .bss
03
The failure follows from Pintos trying to load two segments (00 and
01) at the same address. The failure happens when process.c's load()
tries to load the second segment by calling load_segment(), which calls
install_page().
Passing noseparate-code to ld reverts to the following ELF layout,
and this fixes the problem.
Elf file type is EXEC (Executable file)
Entry point 0x80480ab
There are 3 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x08048000 0x08048000 0x02739 0x02739 R E 0x1000
LOAD 0x00273c 0x0804b73c 0x0804b73c 0x00018 0x00019 RW 0x1000
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10
Section to Segment mapping:
Segment Sections...
00 .text .rodata .rodata.str1.4 .rodata.str1.1
01 .data .bss
02
Signed-off-by: W. Michael Petullo <mike@flyn.org>