Проблема с GNUARM 4.1.0, Неправильно инициализируются глобальные переменные Опции

[Alexey75]

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

[makc]

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

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

[Alexey75]

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

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

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

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

Прикрепленные файлы

 archive.zip ( 5.03 килобайт ) Кол-во скачиваний: 28

 

[makc]

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

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

[Alexey75]

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

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

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

[makc]

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

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

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

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

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