Не, исключения - штука в принципе отличная. Но места и памяти - жалко.

Если бы оно (fno-exceptions) всегда работало, всё было бы чудесно. Хочет человек эксепшны - пожалуйста, не хочет - не надо. Но этот pure virtual портит всю малину.

Ну, совсем-то наверное не надо А вот по fno-exceptions - да.

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

О! идея.
попробую библиотеки скомпилять без исключений. посмотрим что тагда будет. как вариант сборки.

я добавил к проекту следующие файлы и с no-exception, no-rtti ничего лишнего не подключается.

malloc и free свои

у меня также, после введения в проекте синонимов malloc free на свои реализации. я писал что -600% по размеру.
остается вопрос - если эксепщены и RTTI выключены то кто malloc free тянет?
я всетаки соберу две версии libctdc++ одну нормально а вторую с no-exception, no-rtti. а там сравним че получится.

О, супер! Хватило только первого файла (sys.c), и всё стало отлично.

2 klen: наверное так и должны выглядеть эти __cxa_xx() при -fno-exceptions. Остальное, судя по всему, в либах правильно.

свежак для ARM

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

Ситуация такая:
установлен WinAVR.
PATH сначала указывает на кучку свежаков, потом на winavr.
С крайтим свежаком для arm при сборке проекта вываливается mkdir с ошибкой обращения к памяти. С предыдущей сборкой такой ошибки нет, проект собирается корректно (mkdir.exe подсасывается из winavr\utils\bin определённо, потому что более его нигде нет).

C AVR досадно, но не работает avr-size из крайней сборки для avr (хотя, из winavr считает объёмы корректно).

c:\gcc\bin\avr-size.exe: unrecognized option `--mcu=atmega324p'
Usage: c:\gcc\bin\avr-size.exe [option(s)] [file(s)]
Displays the sizes of sections inside binary files
If no input file(s) are specified, a.out is assumed
The options are:
-A|-B --format={sysv|berkeley} Select output style (default is berkeley)
-o|-d|-x --radix={8|10|16} Display numbers in octal, decimal or hex
-t --totals Display the total sizes (Berkeley only)
--common Display total size for *COM* syms
--target=<bfdname> Set the binary file format
@<file> Read options from <file>
-h --help Display this information
-v --version Display the program's version

Как-то так.

Определённо, я что-то делаю не так. Только не пойму, что именно.

ЗЫ можно, для облегчения жизни, бросать ссылки на крайние сборки в первый пост?

Просто при сборке WinAVR донакладывают свои патчи. Почему (из каких соображений) они не попадают в ствол - я не знаю. Способность avr-size принимать конкретный тип контроллера и выдавать с процентом использования - один из таких давно существующих патчей.

Спасибо.
Подумаю, как лучше поступить..

А с mkdir решилось установкой winavr от 20090313 (был 200812xx).
Компилируется теперь без косяков.
Остаётся понять, в чём была проблема.

Уважаемый Klen

Скажите, пожалуйста, для чего нужна libiconv-2.dll, и, как сделать так, чтобы arm-kgp-elf-g++.exe её находил.

Также буду весьма благодарен, если Вы выложите примеры make-файлов, который можно использовать для
компиляции standalone-приложений (.bin) для процессоров ARM7 (LPC2478) и Cortex-M3 (LPC1768)

И еще вопрос: поддерживает ли предложенный Вами openocd примитивный программатор типа Wiggler?


Заранее благодарен

>Скажите, пожалуйста, для чего нужна libiconv-2.dll, и, как сделать так, чтобы arm-kgp-elf-g++.exe её находил.
это внешняя библа для того подержки кодировок разных языков
тут написано http://www.gnu.org/software/libiconv/
вообщето я ее в архив кладу(но мог както пропустить). оно должно лежать в /bin

>Также буду весьма благодарен, если Вы выложите примеры make-файлов, который можно использовать для
>компиляции standalone-приложений (.bin) для процессоров ARM7 (LPC2478) и Cortex-M3 (LPC1768)

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

максимум чем я могу помоч так это отослать вас к манам по make и положить пример для STM32F103RET6 в котором демонстрируется в числе прочего как юзать функциональность make. но МАНЫ ВПЕРЕД!!!


>И еще вопрос: поддерживает ли предложенный Вами openocd примитивный программатор типа Wiggler?
ага, сам виглером шил поначалу. есть особенность. Вы должны поставить стронние дрова для паралельного порта. это процедура в инете описана.

Добрый вечер (ночь/утро/день) !



Я не правильно поставил вопрос. Я хотел узнать ключи компилятора, по которым он определяет для какого процессора
генерировать код. Это конечно можно в интернете узнать и проверить на железке, но как раз ее у меня пока инет.



У меня в конфигурационном файле для openocd есть такие слова:
#interface
interface parport
parport_port 0x378
parport_cable wiggler

На этот конфиг, я натравливал приложение с именем openocd-pp.exe. И драйвер какой-то был установлен.
Теперь, если запустить Ваш openocd, появляется сообщение:
Error: The specified JTAG interface was not found (parport)
The following JTAG interfaces are available:
1: ft2232
2: presto

То есть параллельный порт как бы и не подразумевается этим openocd, если я правильно понял.
Непонятно. Нужна такая dll'ка, чтобы параллельный порт "прикинулся" ft2232, что ли?
Вы говорите, что "эта процедура в инете описана". Напишите ссылку, пожалуйста.

Заранее благодарен

увидите какие ключи говорят для какого проца компилить
arm-kgp-elf-gcc --target-help

косяг у меня - я конфигурил oocd без поддержки LPT.
дособираю новую сборку - там будет oocd рулить lpt. Вы как раз и протестируете.

Добрый вечер (ночь/утро/день)!

Как у Вас обстоят дела с новой сборкой? Не терпится протестировать!

хорошо обстоят дела - проблема в одном. нада напрячся и нажать на кнопки файлзиллы чтоб положить все на фтп

я щас добавляю LTO оптимизацию для mingw32-host arm-target порта GCC. тут есть проблемки - нада ручками писать код - релизовать врапер unix системных вызовов из sys/mman.h ( mmap() munmap() mlock()..... ) средствами Win32 API. это отображение механизм файлов. Если кто знает готовый врапер для mingw32 тыкните носом - дело ускорится.

результатом будет оптимизация при линковке (LinkTimeOptimization - LTO ), поидее еще болще мусора должно выкидыватся но самое главное линкер сможет двигать куски кода более свободно, например рядом распологать взаимосвязанные функции и и спользовать короткие и более быстрые вызовы, капример rcall вместо call в AVR или чтото в этом роде. Нада разбиратся детально как это с умом приложить http://gcc.gnu.org/wiki/LinkTimeOptimization