Questions on arm-gcc linking: .ARM.exidx and .relocate sections

I studied the output files from a build process of Atmel Studio project for SAMD20 MCU that is a Cortex-M0+.
The IDE uses arm-gcc compiler.
The strange thing I noticed was the last Flash address used: in lss it is 2'06a4. Indeed lss file ends with:
00020694 <_fini>:
    20694: b5f8      push {r3, r4, r5, r6, r7, lr}
    20696: 46c0      nop ; (mov r8, r8)
    20698: bcf8      pop {r3, r4, r5, r6, r7}
    2069a: bc08      pop {r3}
    2069c: 469e      mov lr, r3
    2069e: 4770      bx lr
000206a0 <__fini_array_start>:
    206a0: 000008a5 .word 0x000008a5
However the map file emits additional 8 bytes in .ARM.exidx section:
  *(.fini_array)
  .fini_array    0x000206a0        0x4 c:/program files (x86)/atmel/studio/7.0/toolchain/arm/arm-gnu-toolchain/bin/../lib/gcc/arm-none-eabi/6.3.1/thumb/v6-m/crtbegin.o
  *(SORT(.fini_array.*))
                 0x000206a4                __fini_array_end = .
  *crtbegin.o(.dtors)
  *(EXCLUDE_FILE(*crtend.o) .dtors)
  *(SORT(.dtors.*))
  *crtend.o(.dtors)
                 0x000206a4                . = ALIGN (0x4)
                 0x000206a4                _efixed = .
                 [!provide]                PROVIDE (__exidx_start, .)
.vfp11_veneer   0x000206a4        0x0
  .vfp11_veneer  0x000206a4        0x0 linker stubs
.v4_bx          0x000206a4        0x0
  .v4_bx         0x000206a4        0x0 linker stubs
.iplt           0x000206a4        0x0
  .iplt          0x000206a4        0x0 c:/program files (x86)/atmel/studio/7.0/toolchain/arm/arm-gnu-toolchain/bin/../lib/gcc/arm-none-eabi/6.3.1/thumb/v6-m/crtbegin.o
.ARM.exidx      0x000206a4        0x8
  *(.ARM.exidx* .gnu.linkonce.armexidx.*)
  .ARM.exidx     0x000206a4        0x8 c:/program files (x86)/atmel/studio/7.0/toolchain/arm/arm-gnu-toolchain/bin/../lib/gcc/arm-none-eabi/6.3.1/thumb/v6-m\libgcc.a(_udivmoddi4.o)
                 [!provide]                PROVIDE (__exidx_end, .)
.eh_frame       0x000206ac        0x0
  .eh_frame      0x000206ac        0x0 c:/program files (x86)/atmel/studio/7.0/toolchain/arm/arm-gnu-toolchain/bin/../lib/gcc/arm-none-eabi/6.3.1/thumb/v6-m/crtbegin.o
.rel.dyn        0x000206ac        0x0
  .rel.iplt      0x000206ac        0x0 c:/program files (x86)/atmel/studio/7.0/toolchain/arm/arm-gnu-toolchain/bin/../lib/gcc/arm-none-eabi/6.3.1/thumb/v6-m/crtbegin.o
.jcr            0x000206ac        0x0
  .jcr           0x000206ac        0x0 c:/program files (x86)/atmel/studio/7.0/toolchain/arm/arm-gnu-toolchain/bin/../lib/gcc/arm-none-eabi/6.3.1/thumb/v6-m/crtbegin.o
.igot.plt       0x000206ac        0x0
  .igot.plt      0x000206ac        0x0 c:/program files (x86)/atmel/studio/7.0/toolchain/arm/arm-gnu-toolchain/bin/../lib/gcc/arm-none-eabi/6.3.1/thumb/v6-m/crtbegin.o
                 0x000206ac                . = ALIGN (0x4)
                 0x000206ac                _etext = .
What is .ARM.exidx section? Its contents in my case is (from the .hex):
:0806A400149BFF7F0100000020
However I noticed another strange thing. The hex file that I use for production doesn't end at address 2'06AC, but at address 2'08CC. There are other 0x220=544 bytes.
After exploring the output files I found the .relocate sections in map file. It seems it is linked to RAM (0x2000'0000):
.relocate       0x20000000      0x220 load address 0x000206ac
                 0x20000000                . = ALIGN (0x4)
                 0x20000000                _srelocate = .
  *(.ramfunc .ramfunc.*)
  *(.data .data.*)
  .data.memset_func
                 0x20000000        0x4 src/mbedtls/library/platform_util.o
  .data.g_interrupt_enabled
                 0x20000004        0x1 src/ports/samd20/ASF/common/utils/interrupt/interrupt_sam_nvic.o
                 0x20000004                g_interrupt_enabled
  *fill*         0x20000005        0x3
  .data.tzinfo   0x20000008       0x40 c:/program files (x86)/atmel/studio/7.0/toolchain/arm/arm-gnu-toolchain/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/lib/thumb/v6-m\libc_nano.a(lib_a-gettzinfo.o)
  .data._impure_ptr
                 0x20000048        0x4 c:/program files (x86)/atmel/studio/7.0/toolchain/arm/arm-gnu-toolchain/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/lib/thumb/v6-m\libc_nano.a(lib_a-impure.o)
                 0x20000048                _impure_ptr
  .data.impure_data
                 0x2000004c       0x60 c:/program files (x86)/atmel/studio/7.0/toolchain/arm/arm-gnu-toolchain/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/lib/thumb/v6-m\libc_nano.a(lib_a-impure.o)
  .data.__global_locale
                 0x200000ac      0x16c c:/program files (x86)/atmel/studio/7.0/toolchain/arm/arm-gnu-toolchain/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/lib/thumb/v6-m\libc_nano.a(lib_a-locale.o)
                 0x200000ac                __global_locale
  .data._tzname  0x20000218        0x8 c:/program files (x86)/atmel/studio/7.0/toolchain/arm/arm-gnu-toolchain/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/lib/thumb/v6-m\libc_nano.a(lib_a-tzvars.o)
                 0x20000218                _tzname
                 0x20000220                . = ALIGN (0x4)
                 0x20000220                _erelocate = .
.bss            0x20000220     0x611c load address 0x000208d0
                 0x20000220                . = ALIGN (0x4)
                 0x20000220                _sbss = .
                 0x20000220                _szero = .
However I think it is linked in Flash and copied in RAM during startup code.
 From what I understand, they are global/static variables initialized in the declaration (with a startup value).