[klen 1]

свежак для ARM

 

www.klen.org/Files/DevTools/kgp_arm_eabi_20100226.7z

[GenaSPB 11]

свежак для ARM

 

www.klen.org/Files/DevTools/kgp_arm_eabi_20100226.7z

 

Как и в предидущем случае, затаскивается весь stdio. Даже не сравнить.

 

 .text          0x001066f0      0x1b0 c:/kgp_arm_eabi_20100226/bin/../lib/gcc/arm-kgp-eabi/4.5.0\libgcc.a(libunwind.o)
                0x001066f0                __restore_core_regs
                0x001066f0                restore_core_regs
                0x0010670c                __gnu_Unwind_Restore_VFP
                0x00106714                __gnu_Unwind_Save_VFP
                0x0010671c                __gnu_Unwind_Restore_VFP_D
                0x00106724                __gnu_Unwind_Save_VFP_D
                0x0010672c                __gnu_Unwind_Restore_VFP_D_16_to_31
                0x00106734                __gnu_Unwind_Save_VFP_D_16_to_31
                0x0010673c                __gnu_Unwind_Restore_WMMXD
                0x00106780                __gnu_Unwind_Save_WMMXD
                0x001067c4                __gnu_Unwind_Restore_WMMXC
                0x001067d8                __gnu_Unwind_Save_WMMXC

 

После этого уже всё остальное.

Изменено 27 февраля, 2010 пользователем Genadi Zawidowski

[klen 1]

это че? проблема то в чем?

Вы С++ код компиляете? в таком случае добавте -fno-rtti -fno-exceptions мусор должен кончится

[GenaSPB 11]

это че? проблема то в чем?

Вы С++ код компиляете? в таком случае добавте -fno-rtti -fno-exceptions мусор должен кончится

Нет, обычный C код. Проект выкладывал в этой теме. А проблема в лишних 20 килобайтах которые явно не могут работать - всё на голом железе без имитации или заглушек на io.

Вы собирались библиотеку перекомпилить для того, чтобы unwinding не использовался. В этой версии ещё нет?

 

Проект выложен здесь: http://electronix.ru/forum/index.php?showt...st&p=712754

Изменено 27 февраля, 2010 пользователем Genadi Zawidowski

[klen 1]

это чтото непонятное.

1. собираю проект С, никаких хвостов из libunwind в бинарнике нет. только содержательный код.

2. собираю проект С++, вижу содержательный код + код поддержки rtti exceptions.

3. собираю проект С++ -fno-rtti -fno-exceptions , вижу опять же содержательный код, выкинулось 35 килобайт кода.

 

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

ну по моему разумению ну никак из libunwind.o чтото попасть с бинарник C-проекта не должно.

 

и еще! а как это у вас собралось? раз уж libunwind запихнулась в проект то откуда линкер умудрился найти символы _exidx_start __exidx_end которые нужны в модуле unwind-arm.c?

может проблема проистекает из crt кода

[GenaSPB 11]

1. собираю проект С, никаких хвостов из libunwind в бинарнике нет. только содержательный код.

 

Если библиотека собрана с поддержкой исключений - и вызывается такая функция (в моём случае, например, div или ldiv) - как с этим быть?

 

Символы я определил (ондин из коллег здесь в теме выложил исправленный) в линк-скрипте. Можете выкинуть - тогда вообще не соберётся.

 

Проекьт здесь в теме выложен - можете его "препарировать"? Я думаю, не только мне интересно. Или проблема только у меня?

Изменено 27 февраля, 2010 пользователем Genadi Zawidowski

[klen 1]

Если библиотека собрана с поддержкой исключений - и вызывается такая функция (в моём случае, например, div или ldiv) - как с этим быть?

 

Символы я определил (ондин из коллег здесь в теме выложил исправленный) в линк-скрипте. Можете выкинуть - тогда вообще не соберётся.

 

Проекьт здесь в теме выложен - можете его "препарировать"? Я думаю, не только мне интересно. Или проблема только у меня?

 

с помощью грязных рук и такойто матери собрал Ваш проект. незнаю будет ли он работать, но то что выплюнул линкер имеет

text 38172

data 0

bss 2496

 

objdump -t говорит что в бинаре нет символов похожих на unwind

 

долго мучалчя пока собралось - правил makefile, ld скрипт, добавил один файл с затычками системных вызовов ( _kill _exit)

 

у Вас какой размер выдает?

 

libgcc в которой операции с численными типами и NEWLIB libc - это С библиотеки и собрать их с исключениями нельзя потому что их в С языке неиметсо!

 

вкладываю бинарник который получилсо

tc1_rom.elf.7z

[GenaSPB 11]

с помощью грязных рук и такойто матери собрал Ваш проект. незнаю будет ли он работать, но то что выплюнул линкер имеет

text 38172

data 0

bss 2496

 

objdump -t говорит что в бинаре нет символов похожих на unwind

 

долго мучалчя пока собралось - правил makefile, ld скрипт, добавил один файл с затычками системных вызовов ( _kill _exit)

 

у Вас какой размер выдает?

 

libgcc в которой операции с численными типами и NEWLIB libc - это С библиотеки и собрать их с исключениями нельзя потому что их в С языке неиметсо!

 

вкладываю бинарник который получилсо

 

До модификаций с комплектом Вашей сборки было около 50 килобайт, с yagarto 31 килобайт. Попробую добавить затычки на упомянутые функции - соберу и проверю, вечером.

 

text 38172 - похожее значение было и с yagarto.

Прошить прямо ваш elf не могу, так как плата существует в нескольких слегка отличающихся конфигурайиях.

Изменено 27 февраля, 2010 пользователем Genadi Zawidowski

[klen 1]

архив всего проекта который можете скомпилять и все проверить.

добавлять затычки Вам не нада они уже есть в libc

видимо дело всетаки в скрипте линкера, его я наиболе изменил по сравнеию с другим

 

деление всетаки нада проверить! зашейте проверьте и сообщите результат

 

результат в 38 kb устраивает?

TC1.7z

[klen 1]

нашел концы этого природного явления!

все дело в использовании деления значений целочисленного типа uint64_t или его производных.

 

факт на рыло, как это понимать я пока незнаю

 

 

если в С программе использовать встроенный целый тип 64 бита и есть деление то Unwind прилазит в код!

 

ну че? берем фонарь и спускаемся в подвал libgcc

__gnu_uldivmod_helper

__udivdi3

вот эти две вытягивают раскрутку стека.нашел концы этого природного явления!

все дело в использовании деления значений целочисленного типа uint64_t или его производных.

 

факт на рыло, как это понимать я пока незнаю

 

 

если в С программе использовать встроенный целый тип 64 бита и есть деление то Unwind прилазит в код!

 

ну че? берем фонарь и спускаемся в подвал libgcc

__gnu_uldivmod_helper

__udivdi3

вот эти две вытягивают раскрутку стека.

 

 

ФИСЕ. нашел где это пофиксить, но пока токо руками получаетсо собрать libgcc. В следующей сборке эта проблема будет решена

[Konqere 0]

to klen: А будет ли свежак для mips или уже не поддерживается данное направление?

[klen 1]

to klen: А будет ли свежак для mips или уже не поддерживается данное направление?

 

будет.

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

[kimstik 0]

хех

надо свиснуть представителям микрочипа

они сами должны ради такого дела персонально домой к тебе приехать и вручить кит pic32!!

по крайней мере это в их интересах :)

[_Pasha 0]

по крайней мере это в их интересах :)

Некрочип, продающий гццшный С30 за бабло, кроме недоуменного пожатия плечами, более никаких эмоций не вызыват.

[kimstik 0]

Некрочип, продающий гццшный С30 за бабло, кроме недоуменного пожатия плечами, более никаких эмоций не вызыват.

Ну и пусть себе продают. Значи есть те, кто покупает. Им отчитываться надо и саппорт...

А те кто с руками и у кого есть немного(или много) времени компилят сами.

 

klen: респект тебе. У тебя одна из самых толковых сборок. У меня нервов не хватает самому так собрать :)