Здравствуйте!
Загвоздка с самосборным компилятором arm-eabi-gcc. Собирал этим скриптом. Простейшая скомпилированная программа работает корректно. После добавления ряда математических вычислений и соответствующих sprintf программа начала зависать, причем в разных местах, в зависимости от того, какую строку закомментировать. Иногда вываливается в data и prefetch abort. В итоге дошло до того, что если удачно раскидать по тексту программы разный хлам типа uart_write("###########") и while(1>5), то можно добиться, чтобы она отрабатывала успешно. Причем если скомпилировать ту же программу в IAR, то работает корректно без дополнительных вставок. Но IAR ломаный, для этого проекта не годится. В чем может быть причина? В скрипте или в исходниках?

P.S. build.sh загрузить не дали, даже после убирания расширения. Пришлось сделать rar.

Похоже на то, что у вас стек не выровнен на 8 байт.

Прикрепил Startup. Стек определяю в нем. Если не ошибаюсь, стек выровнен. Возможно чего-то не догоняю.

не доверяю я этому sprintf (

Да, значит дело не в этом. Ещё вариант - не хватает кучи (она в последнее время требуется для printf).
Если всё же грешите на компилятор, попробуйте собрать каким-нибудь проверенным.

Готовый компилятор от Codesourcery работает только с порядком liitle-endian. Отпадает. Нужен big-endian.
Перепробовал довольно много сочетаний разных версий пакетов для сборки. Скомпилированные бинарники работают по разному, но правильно не заработал ни один. На всякий случай прикрепляю скрипт линкера. Может в нем погрешность?
И насчет кучи. Задавался таким вопросом, бродил по форуму, по интернету, пробовал объявлять секцию, но куча так и осталась незадействованной. Malloc нормально работает без кучи, а больше ничего и не надо было. Если есть, дайте, пожалуйста, ссылки на толковые источники информации по кучам.

Какая-то странная секция - "CONSTRUCTORS". Современные компиляторы помещают конструкторы в секцию ".init_array". Хотя у вас всё равно конструкторы не вызываются из стартапа.
Посмотрите ещё вот этот скрипт для примера, может быть что-то там найдёте полезного.

Так не бывает. Malloc как раз выдаёт память из кучи. Куча обычно начинается с позиции _end, определённой в скрипте линкера.
Чтобы контролировать это, попробуйте собрать свой проект с ключом линкера -nostartfiles. Линкер должен будет заругаться на неопределённые имена типа _sbrk() и проч. Тут вы ему подсунете свои заглушки для системных функций, примерно как здесь.

Я имел в виду не нужно специально объявлять кучу. Написал по идиотски.
-nostartfiles и так указано. Вот после -nostdlib начинает ругаться именно так. Только счастья не прибавляется. Заглушки, в том числе отдельный printf.c, помогают избежать зависаний, но на вопрос не отвечают. Хочется в полной мере использовать newlib.
Добавил в начало программы такие строки:

и получил такой результат:

Но непонятно, как "подключить" результат sbrk к sprintf в плане использования им этой кучи. Вообще sbrk выполняет очень сложную задачу по складыванию двух чисел и возврату результата из внутренней переменной. Я так понял, что для задания кучи, которую будет использовать newlib, нужно вызывать другую функцию, которая уже сама вызовет sbrk. Только не нашел какую.

Так заглушки как раз и позволяют использовать newlib. Они реализуют, скажем так, платформенно-зависимые вещи. _sbrk() - выделение кусочка памяти для malloc(), _write() - вывод символов на устройство вывода для printf().
Просто у вас откуда-то подцепляются умолчательные реализации этих заглушек.
Если ключ -nostdlib отключает эти умолчательные реализации - то именно он и нужен. Он не отключит возможность использовать newlib.

Не нужно ничего больше вызывать. malloc() вызывает _sbrk(). Вы пишете свою реализацию _sbrk(), и всё начинает работать.

Ничего не надо подключать. Все уже подключено до нас. Где-то в процессе выполнения sprintf() будут вызваны malloc()/free(), которые и работают с кучей. От Вас лишь требуется предоставить sbrk().


Нет никакой функции, которую надо вызвать "для задания кучи". Все, что от Вас требуется - это предоставить функцию sbrk(). Когда newlib'у нужен кусок памяти из кучи, он вызывает вашу sbrk(), передавая ей требуемый размер. Если у Вас в куче есть кусок такого размера, sbrk возвращает адрес этого куска. Таким образом, использоваться будет та область памяти, на которую укажет ваша sbrk().

Контора больше ждать не захотела и купила IAR EWARM. Землю носом рыть теперь не надо, но интерес остался. На досуге буду дальше копать. Спасибо всем откликнувшимся.

Тема давняя, но точку поставлю. Пришлось разобраться после очередной смены местожительства и, соответственно, вывески. Скрипты для сборки компилятора вполне рабочие. Подсовываем новые пакеты и получаем новые версии. Не давал спокойно работать скрипт линкера. Для запуска программы из ОЗУ оказалось вполне достаточно такого скрипта:

Куча размером 4096 байт появляется после строчки . = . + 4096;. Можно явно указать секцию .heap, задать ее размер, назвать как угодно, главное в конце указакть PROVIDE(end = .);. Этим и определяется размер кучи. Куча появляется в просвете между адекватными секциями и end. Секцию data в этом случае копировать не нужно.