Why does LD map sections in this manner for ELF64 on Ubuntu 18.04

Question

Using

GNU ld (GNU Binutils for Ubuntu) 2.30

in a makefile

App: App.o Init.o SubRtx.o
    ld -oApp SubRtx.o Init.o App.o

App.o: App.asm
    nasm -g -felf64 App.asm -oApp.o

Init.o: Init.asm
    nasm -g -felf64 Init.asm -oInit.o

SubRtx.o: SubRtx.asm
    nasm -g -felf64 SubRtx.asm -oSubRtx.o

clean:
    rm *.o App

Segments are mapped in the following manner.

[ 1] .text    PROGBITS 4000b0 0000b0 00023f 00  AX  0   0 16
[ 2] .rodata  PROGBITS 4002f0 0002f0 000018 00   A  0   0 16
[ 3] .data    PROGBITS 600310 000310 0000d0 00  WA  0   0 16

In my assembler files, sections are simply declared as section .data and section .rodata and by design App.o is the only file with a .data section, hence it is why it is mapped @ 0x600310

I might be getting confused with Windows or maybe even ELF32, but I want to seem to remember by default segments started @ even 4K boundaries. IE: .data would be @ 0x600000 or at least 0x601000, but copying the contents of TEXT section to DATA right from 0x400000 and then DATA not starting until 0x310 seems to be an unnecessary waste.

Intentionally, my application is completely self contained (static linkage) and interfaces with OS via SYSCALL exclusively. Code works as expected and I've even erased contents from 0x600000 -> 0x60030f without adverse implications, but am still curious why does this happen.

Answer 1

Segments are mapped in the following manner.

These are sections, not segments (they are not the same thing).

.data would be @ 0x600000

It is impossible to mmap the data segment that starts at offset 0x310 in the executable file to any location in memory that is not equal 0x310 modulo page size.

See also this or this answer.