Народ, помогите все по полкам разложить.
Все началось с того, что хотел прикрутить *printf из newlib. В проекте используется FreeRTOS.
По прошлому опыту ожидал, что сразу возникнут ошибки линковки _sbrk ,_write, _read и т.д.
Но все скомпилировалось нормально . ToolChain от klen'а (спасибо ему)
При запуске из под отладчика выпал в _swiwrite на инструкции bkpt. Копаясь в исходниках newlib 1.19 нашел где это.
Правильно ли я понял, что это из-за сборки newlib без ключа --disable-newlib-supplied-syscalls?
Дальше я скачал yagarto, заменил компилятор. и ошибки линковки возникли (я впервые был ряд ошибкам )))
Реализовал syscalls, и все заработало.
Но!!! printf использует malloc, malloc вызывает _sbrk для получения памяти. в исходниках для блокировки кучи используется
вызовы _malloc_lock и _malloc_unlock. Отладчиком смотрел, они пустые (и в исходнике newlib их смотрел)



Значит из многопоточной среды вызывать printf черевато (и malloc тоже)
собственно вопросы:

1. можно ли заставить ToolChain klen'a работать с моими syscalls без пересборки newlib
2. как залочить кучу newlib в проекте FreeRTOS (пересобирать что-ли без __SINGLE_THREAD__)
3. если прошлое нельзя, то может наоборот заставить newlib использовать vPortMalloc из FreeRTOS

За любую помощь заранее благодарен!

Написать в одном из исходных файлов проекта свою функцию malloc (ну и free, разумеется), которая будет вызывать vPortMalloc и прилинкуется взамен библиотечной.

в исходниках newlib увидел MALLOC_PROVIDED, никто не пробовал объявлять? тогда вроде newlib не будет свою malloc компилить

malloc и free писать не надо, они уже написаны. Писать надо __malloc_lock() и __malloc_unlock(). Об этом, кстати, прямым открытым текстом написано в документации. Также скорее всего потребуется переписать _sbrk() в плане проверки исчерпания кучи. Для работы printf необходимо также реализовать системный вызов _write.

так __malloc_lock() и __malloc_unlock() не определяются из-за ошибки линкера!



нашел вот это
mail архив newlib

этож чтож - пересобирать?
пока придумал удалить mlock.o из libc.a чтоб линкер не ругался, кто что думает

пока нашел сырое решение
опция линкера


теперь я могу определить свой
void __malloc_lock (struct _reent *r)
и он вызывается!
только вот криво это, буду копать дальше

Вобщем решил сделать так:

В программе реализовал лок кучи через FreeRTOS



чтоб не было ошибки линковки - выполняю команду
arm-none-eabi-ar dv libc.a lib_a-mlock.o

libc.a - который используется в данный момент ( у меня это arm-none-eabi/lib/thumb/v7m\libc.a поскольку cortex-m3), зависит от multilib

она удаляет из архива объектник с mlock.

Все. буду тестировать newlib'ский malloc, мне кажется он должен быть понадежнее, чем FreeRTOS'овский.

Сообщение отредактировал podelkin - Oct 25 2011, 10:18

??? Ошибка "multiple definition", наоборот, означает, что символ __malloc_lock определен более одного раза. При этом линкер сообщает, при загрузке какого модуля эта ошибка возникла, и где (в каком модуле) этот символ был определен раньше.

Могу предположить следующее: когда Вы делали собственные версии __malloc_lock и __malloc_unlock, допустили опечатку в имени последней. В результате после загрузки модулей вашего проекта линкер не находит __malloc_unlock и загружает библиотечный mlock.o. А там __malloc_lock, который уже есть в вашем проекте!


ИМХО это не решение, а маскировка проблемы. Если верно сделанное мной выше предположение, то, действительно, будет вызываться ваш __malloc_lock, но вместо вашего __malloc_unlock будет вызываться "пустышка" из библиотеки...

Я бы Вам посоветовал разобраться-таки, почему линкер грузит библиотечный mlock.o, если кроме __malloc_lock и __malloc_unlock там ничего нет. Посмотрите, что там в map-файле на этот счет говорится...

Сообщение отредактировал alx2 - Oct 26 2011, 04:18

Я тогда вообще не понимаю, что у Вас происходит... Если линкер загружает mlock.o из библиотеки, значит в вашем проекте присутствует неопределенный символ, имеющийся в mlock.o. Но тогда после удаления mlock.o из библиотеки линкер должен вываливаться с ошибкой "undefined reference to"... Если же символы, содержащиеся в mlock.o проекту не нужны (а так и должно быть, ибо в проекте есть собственные __malloc_lock и __malloc_unlock), какого черта линкер пытался его загружать?...

Может покажете всю команду, которой линкуется ваш проект?

Все линкуется как обычно.
На mlock ссылается сам malloc.
но в исходниках newlib __malloc_lock вызывает __lock_acquire, который определен по умолчанию как

то есть символ __malloc_lock в библиотеке есть, но он ничего не делает, только мешает определить свой __malloc_lock.
Поэтому и пришлось выкинуть mlock.o из libc.a, чтоб спокойно определить свои __malloc_lock, который бы защитил кучу в много поточной среде.
После 2ух дней тестов все работает. Уже пишу, поскольку не нашел никакой информации на форуме по использованию
malloc из newlib (и *printf по зависимостям также) из многопоточной среды, надеюсь кому-то поможет.
кстати исправил определение своих символов на :

чтоб не терять прерывания во время работы с памятью
Все работает

Я не знаком с обычаями линковки.

malloc не ссылается на mlock. Он ссылается на __malloc_lock и __malloc_unlock. Но они уже определены в вашем проекте! Таким образом, эти ссылки будут удовлетворены уже при загрузке malloc.o, и никакой mlock.o из библиотеки он загружать не должен (никаких других символов кроме этих двух в mlock.o нет). Следовательно, мешать он ничему не должен, и что там написано в исходниках newlib, не должно иметь никакого значения...

Как бы то ни было, рад, что у Вас все работает.

Ну и вот для примера:

Как видите, у меня mlock не прилинкован, и ничему не мешает...

Странно, может из-за кэша на работе Ваш пост от Oct 26 2011, 08:12 я увидел только сейчас.

сейчас попробовал скомпилировать простейший пример из поста выше и все собралось вернул lib.a к первоначалному виду и мой проект теперь компилица без ошибок
Какого лешего gcc раньше тянул mloc.o из библиотеки я так понял((
поначалу тоже подумал что я ошибся в написании __malloc_unlock, но тогда бы у меня не собралось бы приложение после выкидывания mloc.o из libc.a
(к тому же я смотрел отладчиком мои __malloc_lock и __malloc_unlock прилежно вызывались, то есть были написаны без ошибок)
Остановлюсь на том что где-то кривизна моих рук ускользнула от моего взгляда...
Вообщем alx2 респект
А я теперь умею шаманить с символами и знаю ключ

который нафиг не нужен