What is actually loaded here and different hexdump outputs on util-linux hexdump and on cutter and ghidra's hexdump

Question

I was trying to understand what segment of file gets loaded by fourth LOAD header on phdr array. First 6 headers are shown below from readelf

 Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000000040 0x0000000000000040
                 0x0000000000000268 0x0000000000000268  R      0x8
  INTERP         0x00000000000002a8 0x00000000000002a8 0x00000000000002a8
                 0x000000000000001c 0x000000000000001c  R      0x1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000 //file portion till .text
                 0x00000000000006c0 0x00000000000006c0  R      0x1000
  LOAD           0x0000000000001000 0x0000000000001000 0x0000000000001000 //.text
                 0x00000000000003c5 0x00000000000003c5  R E    0x1000
  LOAD           0x0000000000002000 0x0000000000002000 0x0000000000002000 //.rodata,.eh_frame_hdr,.eh_frame
                 0x0000000000000170 0x0000000000000170  R      0x1000
  LOAD           0x0000000000002de8 0x0000000000003de8 0x0000000000003de8
                 0x0000000000000270 0x00000000000002d8  RW     0x1000

that memory range between offset and filesiz is completely absent in ghidra and cutter disassembly and is filled with "ff" and is shown as invalid in cutter hexdump. however, when I use hexdump on my terminal, it is not filled with 'ff' as shown by cutter

00002df0  e0 10 00 00 00 00 00 00  01 00 00 00 00 00 00 00  |................|
00002e00  01 00 00 00 00 00 00 00  0c 00 00 00 00 00 00 00  |................|
00002e10  00 10 00 00 00 00 00 00  0d 00 00 00 00 00 00 00  |................|
00002e20  d8 11 00 00 00 00 00 00  19 00 00 00 00 00 00 00  |................|
00002e30  e8 3d 00 00 00 00 00 00  1b 00 00 00 00 00 00 00  |.=..............|
00002e40  08 00 00 00 00 00 00 00  1a 00 00 00 00 00 00 00  |................|
00002e50  f0 3d 00 00 00 00 00 00  1c 00 00 00 00 00 00 00  |.=..............|
00002e60  08 00 00 00 00 00 00 00  f5 fe ff 6f 00 00 00 00  |...........o....|
00002e70  08 03 00 00 00 00 00 00  05 00 00 00 00 00 00 00  |................|
00002e80  d0 03 00 00 00 00 00 00  06 00 00 00 00 00 00 00  |................|
00002e90  28 03 00 00 00 00 00 00  0a 00 00 00 00 00 00 00  |(...............|
00002ea0  84 00 00 00 00 00 00 00  0b 00 00 00 00 00 00 00  |................|
00002eb0  18 00 00 00 00 00 00 00  15 00 00 00 00 00 00 00  |................|
00002ec0  00 00 00 00 00 00 00 00  03 00 00 00 00 00 00 00  |................|
00002ed0  00 40 00 00 00 00 00 00  02 00 00 00 00 00 00 00  |.@..............|
00002ee0  18 00 00 00 00 00 00 00  14 00 00 00 00 00 00 00  |................|
00002ef0  07 00 00 00 00 00 00 00  17 00 00 00 00 00 00 00  |................|
00002f00  48 05 00 00 00 00 00 00  07 00 00 00 00 00 00 00  |H...............|
00002f10  88 04 00 00 00 00 00 00  08 00 00 00 00 00 00 00  |................|
00002f20  c0 00 00 00 00 00 00 00  09 00 00 00 00 00 00 00  |................|
00002f30  18 00 00 00 00 00 00 00  fb ff ff 6f 00 00 00 00  |...........o....|

-->disassembly from cutter
            0x00002de8      invalid
            0x00002de9      invalid
            0x00002dea      invalid
            0x00002deb      invalid
            0x00002dec      invalid
            0x00002ded      invalid
            :and this continues till 0x00003de7

why the difference? what is actually getting loaded by the fourth LOAD ?

The program I'm disassembling is a simple hello world program

#include<stdio.h>
int main()
{
    printf("hello");
}

compiled with gcc version 9.1.0 (GCC)

Answer 1

So I'm still looking for a better understanding but I found that the GNU_RELRO points from 0x03de8-0x04000, which tells me that this is somehow connected to dynamic relocation sections, and running objdump -R gives me this

DYNAMIC RELOCATION RECORDS
OFFSET           TYPE              VALUE 
0000000000003de8 R_X86_64_RELATIVE  *ABS*+0x0000000000001130
0000000000003df0 R_X86_64_RELATIVE  *ABS*+0x00000000000010e0
0000000000004028 R_X86_64_RELATIVE  *ABS*+0x0000000000004028
0000000000003fd8 R_X86_64_GLOB_DAT  _ITM_deregisterTMCloneTable
0000000000003fe0 R_X86_64_GLOB_DAT  __libc_start_main@GLIBC_2.2.5
0000000000003fe8 R_X86_64_GLOB_DAT  __gmon_start__
0000000000003ff0 R_X86_64_GLOB_DAT  _ITM_registerTMCloneTable
0000000000003ff8 R_X86_64_GLOB_DAT  __cxa_finalize@GLIBC_2.2.5
0000000000004018 R_X86_64_JUMP_SLOT  printf@GLIBC_2.2.5

still don't have a clear understanding so I cant mark this question as solved and I dont know why hexdump on both tools differ as indicated in the question.