[AHTOXA 15]

на pure virtual функции, ставятся заглушки, которые могут потянуть за собой какой-то код exeptions, который за собой найдёт что потянуть.

 

Именно так. Я уже как-то писал про это.

[AlexeyVoroshen 0]

Значит такс:

1.проект на С++

В общем, структура кода приблизительно такова:

Главная ф-ция:

ResourceManager RM;

 

[ кусь... ]

 

Здравствуйте.

Хочу поделиться/посоветовать. Пишу на С++.

У меня вроде с разрастанием кода все неплохо стало :)

Даже с virtual, pure virtual и т.д.

Терпимо - <1,5K всяких либ прилинковывается, самое ненужное - libunwind на 432 байта.

 

Что сделал:

1. syscalls_r1.c - обязательно всякие sbrk и др.

2. new_delete_fOS_r1.cpp - new и delete переделал под FreeRTOS, но главное вызываются malloc и free

3. ещё добавил:

 

// При вызове линкера через $(CPP) всё проходит, но из библиотеки libgcc++ в bss помещается много фигни

// (её можно отрубить, включив отбор неиспользуемых функций, но это не всегда надо),

// поэтому определим вызов функции и всё работает при линковке из $(CC)

// call to a pure virtual function happened ... wow, should never happen ... stop

void __cxa_pure_virtual(void) { while(1); }

 

Может и вам поможет :)

Успехов.

[dimay192 0]

Ок... Общее направление действий понял...

Пока решил не заморачиваться за С++ (к сожалению мало времени, чтобы ковырять библы). Перевел тот же проект на С и все встало на места - лишнего не тащит, размер кода пришел в норму...

А разобраться надо будет обязательно! Но пока и так сойдет!

 

/********************************************************

************ Всем спасибо за внимание и участие! ************

********************************************************/

[Trizna 0]

Можно ли в этой сборке заставить gcc генерировать объектники в COFF формате?

По ключикам пробежался, вроде ни чего похожего нет :(

Надо прилинковать ассемблерную функцию скомпилированную gcc к проекту в VS.

[demiurg_spb 0]

почитайте про ELF->COFF converter

 

ИМХО objcopy Вам поможет (доки на binutils почитайте)

[klen 1]

Можно ли в этой сборке заставить gcc генерировать объектники в COFF формате?

По ключикам пробежался, вроде ни чего похожего нет :(

Надо прилинковать ассемблерную функцию скомпилированную gcc к проекту в VS.

 

gcc для x86 выдает объектники и исполняймые в формате PE.

откуда такие сложности? VS таки ассемблер разучился компилять? Вы навно чтото для winCE ваяите?

[Trizna 0]

почитайте про ELF->COFF converter

 

ИМХО objcopy Вам поможет (доки на binutils почитайте)

 

Похоже имеющийся objcopy только под elf заточен :(

d:\TVV\My Dropbox\Temp\cortex>arm-kgp-eabi-objcopy --info

 

 

 

 

BFD header file version (Klen's GCC package (KGP) for ARM/elf platform) 2.20.51.20101005
elf32-littlearm
(header little endian, data little endian)
 arm
elf32-bigarm
(header big endian, data big endian)
 arm
elf32-little
(header little endian, data little endian)
 arm
elf32-big
(header big endian, data big endian)
 arm
srec
(header endianness unknown, data endianness unknown)
 arm
symbolsrec
(header endianness unknown, data endianness unknown)
 arm
verilog
(header endianness unknown, data endianness unknown)
 arm
tekhex
(header endianness unknown, data endianness unknown)
 arm
binary
(header endianness unknown, data endianness unknown)
 arm
ihex
(header endianness unknown, data endianness unknown)
 arm

              elf32-littlearm elf32-bigarm elf32-little elf32-big srec
          arm elf32-littlearm elf32-bigarm elf32-little elf32-big srec

              symbolsrec verilog tekhex binary ihex
          arm symbolsrec verilog tekhex binary ihex

 

Изменено 22 октября, 2010 пользователем Trizna

[klen 1]

для армов только elf, в соff нет нужды, все средсва работают с elf. ELF - промышленный стандарт а coff это поделка микромягких. также как OpenGL и DirectX

 

у вас один выход - коветнуть.

[Trizna 0]

gcc для x86 выдает объектники и исполняймые в формате PE.

откуда такие сложности? VS таки ассемблер разучился компилять? Вы навно чтото для winCE ваяите?

Я ваяю под windows mobile. Армовский ассемблер от микрософта, которым я раньше пользовался не поддерживает Cortex, пришлось использовать gcc? вот мучаюсь пока...

 

у вас один выход - коветнуть.

 

Не подскажете чем?

[klen 1]

Не подскажете чем?

 

ну нада поискать в инете, я не искал. если нет то сами напишите и дайте людям. с форатом ELF нет проблем - есть офицальные доки + бинутилс это сборник примеров как его парсить и модифицировать, вопрос по COFF, говнокодовцы из редмонта дают на него доки?

 

свежак

 

mingw64:

http://klen.org/Files/DevTools/x86_64_kgp_...w32_20101022.7z

 

arm-eabi под x86_64:

http://klen.org/Files/DevTools/kgp_arm_eab..._64_20101022.7z

[injen-d 0]

...

свежак

 

mingw64:

http://klen.org/Files/DevTools/x86_64_kgp_...w32_20101022.7z

 

arm-eabi под x86_64:

http://klen.org/Files/DevTools/kgp_arm_eab..._64_20101022.7z

Распаковал kgp_arm_eabi_x86_64_20101022.7z при попытке запуска пишет, что arm-kgp-eabi-gcc.exe не является приложением Win32

[klen 1]

Распаковал kgp_arm_eabi_x86_64_20101022.7z при попытке запуска пишет, что arm-kgp-eabi-gcc.exe не является приложением Win32

правильно пишет. написано же ''arm-eabi под x86_64" x86_64 это 64 битные винды. для 32битных масдаев я не собрал - давайте медленно но верно относить старье на помойку истории. мож у нас тут комунизм окончательно победил но чтото я сомневаюсь что Вы написали верхний пост с машины у которой 32юитный проц, они ж ужо вроде и не продаются. если сильно нада то соберу 32битную сборку - но хотелосьбы в перспективе от этого отказатся.

 

[injen-d 0]

Понятно. Смутила надпись x86_64, обычно пишут либо х86, либо х64 (насчет корректности записи х64 не знаю, но пишут так почти везде), подумал, что там две версии, а потом не обратил внимания, что в архиве только одна.

ИМХО, не стоит отказываться от х86, ибо всё еще бывают проблемы с дровами для специфических девайсов и с некоторым ПО.

[klen 1]

Понятно. Смутила надпись x86_64, обычно пишут либо х86, либо х64 (насчет корректности записи х64 не знаю, но пишут так почти везде), подумал, что там две версии, а потом не обратил внимания, что в архиве только одна.

ИМХО, не стоит отказываться от х86, ибо всё еще бывают проблемы с дровами для специфических девайсов и с некоторым ПО.

я считаю так - первая хрень это архитектура(читай набор инструкций) вторая это разрадность. поэтому указываю и то и другое.

 

отказыватся НАДА, только не всегда это возможно. нада старатся. на линуксе это произошло вместе с процессорами.

я щас соберу и выложу. хотя нехотелось ;)

[AHTOXA 15]

для 32битных масдаев я не собрал - давайте медленно но верно относить старье на помойку истории.

 

Ну это вы напрасно:) Думаю, что значительно более половины тутошних виндузятников сидит под ХР 32-бит, и ещё какое-то время никуда не двинутся. Особенно в свете того, что, как я читал, 7-я винда не даёт ставить неподписанные дрова (прощайте LPT-шные программаторы с giveio, прощай olimex MSP430-JTAG-TINY, и ещё куча интересных железок.)

Ну или, если говорить только про себя, то лично я пока сижу под ХР 32-бит:)