В выходном файле ELF вместо необходимых значений в секции .data, находятся нули, в результате при инициализации, глобальные переменные вместо необходимых значений получают нули.

У меня тоже GNUARM 4.1.0


И подобных проблем не наблюдается. Глобальные данные имеют свои значения (отличные от нуля) в секции .data. Проверьте свой скрипт линкера или приведите пример исходных текстов, в котором у Вас не происходит корректная инициализация.

Привожу текст скрипта:
/***********************************************************************/
/* */
/* ROM.ld: Linker Script File */
/* */
/***********************************************************************/
ENTRY(_boot)
STACK_SIZE = 0x400;

/* Memory Definitions */
MEMORY
{
ROM (rx) : ORIGIN = 0x00000000, LENGTH = 0x00020000
RAM (rw) : ORIGIN = 0x40000000, LENGTH = 0x00010000
}

/* Section Definitions */
SECTIONS
{
/* first section is .text which is used for code */
.text :
{
*crt0.o (.text) /* Startup code */
*(.text) /* remaining code */
*(.rodata) /* read-only data (constants) */
*(.rodata*)
*(.glue_7)
*(.glue_7t)
} > ROM

. = ALIGN(4);
_etext = . ;
PROVIDE (etext = .);

/* .data section which is used for initialized data */
.data : AT (_etext)
{
_data = .;
*(.data)
} > RAM

. = ALIGN(4);
_edata = . ;
PROVIDE (edata = .);

/* .bss section which is used for uninitialized data */
.bss (NOLOAD) :
{
__bss_start = . ;
__bss_start__ = . ;
*(.bss)
*(COMMON)
. = ALIGN(4);
} > RAM

__bss_end__ = . ;
PROVIDE (__bss_end = .);

. = ALIGN(4);
.stack : /* AT (__bss_end__) */
{
. += STACK_SIZE;
} > RAM

PROVIDE (_stack = .);

_end = . ;
PROVIDE (end = .);

/* Stabs debugging sections. */
.stab 0 : { *(.stab) }
.stabstr 0 : { *(.stabstr) }
.stab.excl 0 : { *(.stab.excl) }
.stab.exclstr 0 : { *(.stab.exclstr) }
.stab.index 0 : { *(.stab.index) }
.stab.indexstr 0 : { *(.stab.indexstr) }
.comment 0 : { *(.comment) }
/* DWARF debug sections.
Symbols in the DWARF debugging sections are relative to the beginning
of the section so we begin them at 0. */
/* DWARF 1 */
.debug 0 : { *(.debug) }
.line 0 : { *(.line) }
/* GNU DWARF 1 extensions */
.debug_srcinfo 0 : { *(.debug_srcinfo) }
.debug_sfnames 0 : { *(.debug_sfnames) }
/* DWARF 1.1 and DWARF 2 */
.debug_aranges 0 : { *(.debug_aranges) }
.debug_pubnames 0 : { *(.debug_pubnames) }
/* DWARF 2 */
.debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) }
.debug_abbrev 0 : { *(.debug_abbrev) }
.debug_line 0 : { *(.debug_line) }
.debug_frame 0 : { *(.debug_frame) }
.debug_str 0 : { *(.debug_str) }
.debug_loc 0 : { *(.debug_loc) }
.debug_macinfo 0 : { *(.debug_macinfo) }
/* SGI/MIPS DWARF 2 extensions */
.debug_weaknames 0 : { *(.debug_weaknames) }
.debug_funcnames 0 : { *(.debug_funcnames) }
.debug_typenames 0 : { *(.debug_typenames) }
.debug_varnames 0 : { *(.debug_varnames) }
}

-----------------------------------------------------------------
Фрагмент инициализации

// Copy initialized data to its execution address in RAM
// -----------------------------------------------------
#ifdef ROM_RUN
ldr r1,=_etext // -> ROM data start
ldr r2,=_data // -> data start
ldr r3,=_edata // -> end of data
1: cmp r2,r3 // check if data to move
ldrlo r0,[r1],#4 // copy it
strlo r0,[r2],#4
blo 1b // loop until done
#endif


С проблемой столкнулся, когда попытался использовать динамическое выделение памяти,
начал разбираться и обнаружил что неправильно работает malloc, позже оказалось, что переменные
не инициализируются.

На первый взгляд все в порядке. Но проблемы могут быть в другом месте: например после инициализации .data в startup'e Вы при инициализации .bss забиваете нулями и .data. Есть и другие варианты.

Что выдает команда arm-elf-objdump -j .data -sh <имя вашего файла.elf> ?
Приведите результаты ее выполнения.

Я извиняюсь я вставил не тот текст скрипта, но мне кажется что суть не меняется, я пристегнул к сообщению архив с файлами: скрипт линкера, crt0.S, и файл с результатом выполнения
arm-elf-objdump -j .data -sh <имя файла.elf>

В результате этой команды видно, что данные есть в секции .data, но при симуляции в GDB данные для инициализации обнуляются

Если мне не изменяет память, то Ваша проблема при симуляции в GDB только в том, что Вы в коде инициализации сами пытаетесь инициализировать ту область памяти, где должна лежать секция .data. Суть проблемы с том, что GDB сам загружает секцию .data в память, когда читает lpc_os.elf, а Вы ее потом затираете в startup'e. Иными словами, для правильной симуляции в GDB нужно закоментировать инициализацю .data в памяти (ее копирование) в crt0.S. При этом в финальной версии кода (для реального устройства) эта инициализация должна присуствовать.

Спасибо, я понял, в принципе я так и обходил эту проблему, просто я сомневался, что делаю правильно.

Пожалуйста.
Сомневаться тут не в чем, т.к. GDB ведет себя точно так же, как и любой загрузчик исполняемых файлов в любой ОС - подготавливает секции исполняемого файла и раскладывает их по местам, прописанным в заголовках секций.

Если есть желание поэкспериментировать, то можно попробовать использовать атрибут (NOLOAD) для output-секций линкер-скрипта. Этот атрибут должен предотвратить загрузку тех секций, для которых он будет указан, загзрузчиком (в том числе и GDB). Правда для секции .data он у меня не заработал, но если ее переименовать в data, то не проверял, но должно работать. Но в этом случае arm-elf-objcopy будет делать неправильный файл прошивки. В общем, идеального способа не видать.