linker script go wrong

Here is the linker script linked by arm-none-eabi-ld

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")  
OUTPUT_ARCH(arm)  
ENTRY(_start)

#define DDR_START 0x80000000
#define DDR_LEN 512M

SECTIONS 
{
    . = DDR_START;
    .ivt : 
    {
            . = . + 0x400;
            *(.ivt)
    } 

    .boot_data :
    {
            __start_boot_data = .;
            *(.boot_data)
    } 

    /* aligned to ease the hexdump read of generated binary */ 
    .dcd_hdr ALIGN(16) : 
    {
            __start_dcd = .;
            *(.dcd_hdr)
    } 

    .dcd_wrt_cmd :
    {
            *(.dcd_wrt_cmd)
    } 

    .dcd_data :
    {
            *(.dcd_data)
    } 

    .text ALIGN(8) : 
    {
            *(.text) 
    } 

    .rodata ALIGN(4) : 
    {
            *(.rodata*)
    }

    .data ALIGN(4) :
    { 
            *(.data*) 
    }

    . = ALIGN(4);  

    _end_of_copy = .;

    .bss ALIGN(4) : 
    { 
            *(.bss)
    }
}

when i link object file by this script i use -Map option to generate a map file

Memory Configuration

Name             Origin             Length             Attributes
*default*        0x00000000         0xffffffff

Linker script and memory map

            0x80000000                . = 0x80000000

.ivt            0x80000000      0x420
            0x80000400                . = (. + 0x400)
*fill*         0x80000000      0x400 00
*(.ivt)
.ivt           0x80000400       0x20 crt0.o

.boot_data      0x80000420        0xc
            0x80000420                __start_boot_data = .
*(.boot_data)
.boot_data     0x80000420        0xc crt0.o

.dcd_hdr        0x80000430        0x4
            0x80000430                __start_dcd = .
*(.dcd_hdr)
.dcd_hdr       0x80000430        0x4 crt0.o

.dcd_wrt_cmd    0x80000420        0x4
*(.dcd_wrt_cmd)
.dcd_wrt_cmd   0x80000420        0x4 crt0.o

.dcd_data       0x80000420      0x1f8
*(.dcd_data)
.dcd_data      0x80000420      0x1f8 crt0.o

.text           0x80000618       0x44
*(.text)
.text          0x80000618        0x0 crt0.o
.text          0x80000618       0x44 led.o
            0x80000618                _start

.glue_7         0x8000065c        0x0
.glue_7        0x00000000        0x0 linker stubs

.glue_7t        0x8000065c        0x0
.glue_7t       0x00000000        0x0 linker stubs

.vfp11_veneer   0x8000065c        0x0
.vfp11_veneer  0x00000000        0x0 linker stubs

.v4_bx          0x8000065c        0x0
.v4_bx         0x00000000        0x0 linker stubs

.iplt           0x8000065c        0x0
.iplt          0x00000000        0x0 crt0.o

.rel.dyn        0x8000065c        0x0
.rel.iplt      0x00000000        0x0 crt0.o

.rodata
*(.rodata*)

.data           0x8000065c        0x0
*(.data*)
.data          0x8000065c        0x0 crt0.o
.data          0x8000065c        0x0 led.o

.igot.plt       0x8000065c        0x0
.igot.plt      0x00000000        0x0 crt0.o
            0x8000065c                . = ALIGN (0x4)
            0x8000065c                _end_of_copy = .

.bss            0x8000065c        0x0
*(.bss)
.bss           0x8000065c        0x0 crt0.o
.bss           0x8000065c        0x0 led.o
LOAD crt0.o
LOAD led.o
OUTPUT(led.elf elf32-littlearm)

.ARM.attributes
            0x00000000       0x18
.ARM.attributes
            0x00000000       0x16 crt0.o
.ARM.attributes
            0x00000016       0x16 led.o

Cross Reference Table

Symbol                                            File
_end_of_copy                                      crt0.o
_start                                            led.o
                                              crt0.o

the question is why .dcd_wrt_cmd and .dcd_data section start from 0x80000420? I think they should start from 0x80000430 and 0x80000434 respectively?

Added#1: the source code is in assemly, it's like this:

.section .ivt, "x"   
    .word 0xffffffff
    ......

.section .boot_data, "x"
    .word 0xffffffff
    ......

.section .dcd_hdr, "x"
    .word 0xffffffff
    ......

.section .dcd_wrt_cmd, "x"
    .word 0xffffffff
    ......

.section .dcd_data, "x"     
    .word 0xffffffff
    ......