One important point of RELRO in combination with BIND_NOW is that the area can be read-only, as that part contains function pointers. Common heap overflow exploits allow overwriting a word, these frequently invoked function pointers make good targets.
LOAD 0x000000 0x0000000000400000 0x0000000000400000 0x0007d4 0x0007d4 R E 0x200000
02 .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame
LOAD 0x000db8 0x0000000000600db8 0x0000000000600db8 0x000258 0x000260 RW 0x200000
03 .init_array .fini_array .jcr .dynamic .got .data .bss
...
GNU_RELRO 0x000db8 0x0000000000600db8 0x0000000000600db8 0x000248 0x000248 R 0x1
08 .init_array .fini_array .jcr .dynamic .got
However, all the sections are part of the second LOAD section which are what actually maps memory and determine the permissions, and those are RW, also with my linker. I don't think the flags on GNU_RELRO have any influence.
It looks like the executable itself takes care of mprotecting this area at start (glibc _dl_protect_relro):
mprotect(0x600000, 4096, PROT_READ) = 0
I experimentally verified that the section is unwritable during runtime, both when linked with bfd and with gold.
This all makes sense, as the dynamic linker does need to write to it to set the pointers in the first place...