Где в нете - не скажу. Есть в комплекте WinAVR в директории source.

Обнаружил непорядок с arm-kgp-elf (c++).
При использовании pure virtual функций

видимо подключается обработка exceptions, несмотря на флаг -fno-exceptions. В результате тянется malloc, который ругается на неопределённый символ end в _sbrk при линковке.

Хотелось бы этого избежать

Пока вышел из положения, объявив функции пустыми:


Но, может, я что-то упустил из виду?

а что стандарт говорит по этому поводу?

нада смотреть. скорее всего можно закомпилять libstdc++ так чтобы вообще исключений не использовались.

у меня в проектке есть virtual void bar() =0, и все линкуется. new и delete переопределены с использованием собственых malloc и free (свой менеждер кучи)

в любом случае спасибо. -fno-exception уменьшило размер .text в 2! раза век учись - дураком помреш,

Сомневаюсь, что там это есть. Как должна реагировать программа при вызове чисто виртуальной функции? Видимо в arm-gcc решили это через какой-то специальный эксепшн. Наверное это не считается обычным exception-ом, и поэтому не регулируется флагом -fno-exceptions. Само по себе это неважно, мне не нравится что тянется malloc. Кто его знает, сколько оно там отожрёт хипа

В msp-gcc использование pure virtual не тянет за собой malloc. Надо проверить на avr-gcc...


Даже не знаю, надо ли это... Думаю, что правильнее сделать, чтобы флаг -fno-exceptions действовал более чётко

что то я вообще сомневаюсь что для arm-elf вообще механизм эксепшенов реализован, так .. хвосты..
нада изучать вопрос и ковырятся...

Должна вызвать переопределенную версию этой функции. Функция переопределяется в классе-потомке. Если в классе-потомке функция не переопределена, то попытка создания объекта такого класса должна вызывать ошибку на этапе компиляции.

Точно, не компилится. Я почему-то был уверен, что там будет только warning. С дельфями перепутал
Тогда вообще непонятно, зачем цепляются исключения...

Оп-па... А что такое там с исключениями? А то я ими довольно широко пользуюсь, до сих пор на неприятности не нарывался... Считаете, на них нельзя так смело полагаться?

а у Вас все работает?
поделитесь опытом, как это происходит.

я довольно смутно представляю как работает С++ в плане исключений применительно к мелким контролерам. поэтому и написал что "неуверен...", нада было написать "незнаю"


2_AHTOXA
и должна вроде..
виртуальные функции работают, тут все ок. я имел ввиду только исключения! VMT как и положено в классах кладется по нулевому смещению, в классе потомке выбирается адресс из нее и все работает, у меня так обертка к задачам FreeRTOS сделана., функцияя кода задачи чисто виртуальная в базовом классе. А вот исключения дело темное!

например происходит обращение к NULL или вообще за диапазоном адресации какойнить шины - ядро генерит чтото типа bus abort а дальше то че? Вот тут видимо в обработчике и нада руками приуручивать механизм обработки исключений(библиотечные вызовы ) к конкретному механизму их генерации (аппаратные прервыания по косякам с памятью например).

для "не сильно мелких процов" типа ARM720... далее, хде есть MMU, Linux, и тд как я думаю эта прикрутка уже сделано в ядре линуха так как ядро и реализация libc конфигуртся под конкретный проц! я хрюнделем хорошо перерыд ядро линуха и uLibc когда делал девас на Тионе c EP9312, там видать в исходниках все это, и как системные вызовы прикручены к железке и тд.

для armv4 armv7 такого нет, может есть? и все работает как у alx2??? мне очень иньтересно

короче говоря я так это понимаю, если не прав то поправте.

в студию приглашаются специалисты по внутренней реализации C++ и отдельно к микрофону alx2, расказать как у него работают С++ исключения и собсно на чем?

Тут вы смешали в кучу исключения ядра ARM и плюсОвые исключения, которые генерятся программистом посредством ключевого слова throw.

Непонятно только, почему при упоминании чисто виртуальных функций подтягивается malloc? Вот что меня волнует более всего

Про исключения - Сергей Борщ уже сказал, это не те исключения.

Да, работает. throw исключение кидает, catch его ловит. Все в соответствии с правилами языка...

свежак для ARM
все кроме openocd 20090724
в OOCD чето сломали, падает при записи в флеш, поэтому положил предыдущую сборку.


www.klen.org/Files/DevTools/kgp_arm_cortex-m3_20090724.7z - обрезанна, для кортекса.
www.klen.org/Files/DevTools/kgp_arm_full_20090724.7z - полня


свежак для win32
также 20090724
www.klen.org/Files/DevTools/kgp_mingw32_20090724.7z

Посмотрел более предметно. Подтягивается не только malloc, подтягиваются-таки и исключения, как я и предполагал.
От банальной замены

на

мой 14-килобайтный проект подрос до 66К

Подтягивается некая __cxa_pure_virtual, за ней write и std::terminate().
А уж из std::terminate() - кранты, _Unwind_SjLj_Register, __cxa_begin_catch, __cxa_end_catch и вся остальная кампания, вплоть до RTTI

Сдаётся мне, что это всё-таки баг, ибо флаг -fno-exceptions запрещает исключения.

ЗЫ. Получается, всё же есть возможность создать экземпляр класса с чисто виртуальной функцией?

зато работают исключения (которые нам нах ненужны на контроллерах)

будет время залезу внутрь и посмотрю че происходит по fno-exceptions, во всяком случае после прересборки мои проекы на 600% ужались.


про malloc в эксепшенах мне уже просветили.
как минимум исключение пытаеся дернуть память чтоб сообщение(или контекст исключения) создать которое передается обработчику.

нахер все это нада вырубать.

ктонить объяснит? есть ситуации когда без исключений не написать кода?