[klen 1]

А что делать с симлинком на /opt/lib (вроде так) в корне? Видимо подразумевается, что надо распаковывать в /opt ?

а кто ссылается? странная линка /opt/kgp-*** /lib может? у меня /opt/lib не существует.

вообще да, у меня все лежит в /opt

положте пока так, я подумаю че сделать чтоб его мотать по файловой системе сожно было куда угодно.

[AHTOXA 14]

а кто ссылается?

Вроде "lib32". Прям в корне архива. Я сейчас не могу посмотреть, у меня линукс дома.

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

Это будет замечательно. А без либ как-нить нельзя? Как у codesourcery? Как они умудрились? По размеру даже меньше, чем ваша сборка, значит не статическая линковка... Правда у них не 64-битная, может в этом дело?

[AHTOXA 14]

Добрался до линукса. Значит так.

Архив. Ругается не 7zip, ругается уже tar. То есть, из kgp_arm_eabi-20110206.tar.7z без проблем извлекается kgp_arm_eabi.tar, а вот уже при распаковке этого tar-а валятся ошибки:

tar: kgp_arm_eabi/lib64/jim: Функция mkdir завершилась с ошибкой: Это не каталог
tar: kgp_arm_eabi/lib64/gcc: Функция mkdir завершилась с ошибкой: Это не каталог
tar: kgp_arm_eabi/lib64/openocd: Функция mkdir завершилась с ошибкой: Это не каталог
...

...и ещё 250 строчек. Как видно, дело в папке lib64. То ли её нет в архиве, то ли что ещё.

Плюс к тому в распакованной папке kgp_arm_eabi имеется симлинк с именем lib64, указывающий на opt/kgp_arm_eabi/lib. Короче, что-то не так заархивировалось :)

 

Ладно, исправляю симлинк, чтоб указывал на ./lib, потом закидываю в этот lib все либы, которые во втором архиве (x86_64-lib-20110206.tar.7z).

Теперь надо закешировать... Пытаюсь:

$ sudo ldconfig /home/me/kgp/lib
/sbin/ldconfig.real: /home/me/kgp/lib/libstdc++.so.6.0.15-gdb.py не является
ELF-файлом -- у него в начале неправильные волшебные байты.

Итог: со второго наскока тоже не получилось, застрял. Жду подсказок :)

 

[AHTOXA 14]

Итог: со второго наскока тоже не получилось, застрял. Жду подсказок :)

Устал ждать, прибил этот libstdc++.so.6.0.15-gdb.py, после этого ldconfig отработал нормально.

Тестовый си-проект, который я приаттачивал к вот этому сообщению скомпилился и заработал, причём размер кода очень порадовал, а размер ОЗУ - наоборот:

                  text    data    bss
Codesourcery     32644    1416    600
        kgp      19396    2244    600

А вот с C++ что-то не срослось:

uart.h: В функции-члене ‘void uart_t<(uart_num_t)0u115200ul>::_ZTv0_n12_
N6uart_tIL10uart_num_t0ELm115200EL7remap_t0EE5putchEc(char)’:
uart.h:116:6: ошибка: invalid argument to gimple call ch

 

ЗЫ. А зачем он ругается по-русски? :)

[klen 1]

>Устал ждать, прибил этот libstdc++.so.6.0.15-gdb.py, после этого ldconfig отработал нормально.

не нада обращать внимание, ldconfig натыкается на нелибу и ругается - так и должно быть

 

>скомпилился и заработал, причём размер кода очень порадовал, а размер ОЗУ - наоборот

как говорил мой учитель - "произведение жопы на голову есть константа заданная в момент рождения человека", или то больше или другое :)

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

 

effect = text*data*bss

 

Codesourcery 32644*1416 = 46223904

kgp 19396*2244 = 43524624

 

если принят такой виртуальный критерий качества то kgp чуток лучше.

 

НО! меня интересует скорость основных циклических трасс кода!!! флеш и озу - разменная монета!! скорость - цель!!

сравните скорость.

 

>А вот с C++ что-то не срослось: В функции-члене ‘void uart_t<(uart_num_t)0u115200ul>::_ZTv0_n12_re

 

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

 

 

>А зачем он ругается по-русски?

ну дык он родися здесь як мы! как же ему еще говорить...

[AHTOXA 14]

не нада обращать внимание, ldconfig натыкается на нелибу и ругается - так и должно быть

Так страшно, по первости-то:)

Кстати, вот список действительно нужных либ:

libcloog.so
libcloog.so.0
libcloog.so.0.0.0
libgmpxx.so
libgmpxx.so.4
libgmpxx.so.4.1.2
libmpc.so
libmpc.so.2
libmpc.so.2.0.0
libppl.so.9
libppl.so.9.0.0
libppl_c.so
libppl_c.so.4
libppl_c.so.4.0.0
libpwl.so
libpwl.so.5
libpwl.so.5.0.0

(Я смотрел на что ругается и по одной добавлял.)

НО! меня интересует скорость основных циклических трасс кода!!! флеш и озу - разменная монета!! скорость - цель!!

сравните скорость.

Пока не могу, мои проекты не компилируются:)

дайте кусок кода который отдельно можно компильнуть.

Вот, тестовый проект: testcase.7z

Не компилится uart.h. Для сравнения там же (в папке src/lib) лежит файлик dbg_uart.h, так вот, он - компилится.

ну дык он родися здесь як мы! как же ему еще говорить...

А ежели у кого редактор настроен на слова "warning", "error"? Нунаф, баловство это.

 

[klen 1]

>Я смотрел на что ругается и по одной добавлял.

ну да, я все кучей закатал, в следующий оах скриптик напишу чтоб тока эти в дистр копировал

 

 

 

>Пока не могу, мои проекты не компилируются:)

тяжело в учении легко в бою.

 

>Вот, тестовый проект: testcase.7z

>Не компилится uart.h. Для сравнения там же (в папке src/lib) лежит файлик dbg_uart.h, так вот, он - компилится.

посмотрю.

 

>А ежели у кого редактор настроен на слова "warning", "error"? Нунаф, баловство это.

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

 

[AHTOXA 14]

посмотрю.

Хорошо. Кстати, я тут полистал этот топик немного назад, и вспомнил, что это уже не первый случай с этим самым "gimple call". Вот предыдущий...

а как тогда у меня эклипс парсит выход компиллера? наверно чтото другое использует для определения....

Он всё засовывает в ошибки - и предупреждения тоже. Видимо по умолчанию.

[klen 1]

.... это уже не первый случай с этим самым "gimple call"

и не последний, я думаю что это разные косяки вылазящие через одно место. оптимзатор GIMPLE представления пилится непрерывно.

[POVRU 0]

Уважаемый, klen. Нет ли возможности собрать такой тул для NIOSII под маздай?

Изменено 23 февраля, 2011 пользователем PVL

[klen 1]

Уважаемый, klen. Нет ли возможности собрать такой тул для NIOSII под маздай?

в офицальной ветке gcc такой таргет не поддерживает, я не нашел. микроблазе поддерживает а nios ненашел. зато на сайте автора плисин есть дистрибутивы тулсов. оттуда чем не устраивает?

[POVRU 0]

в офицальной ветке gcc такой таргет не поддерживает, я не нашел. микроблазе поддерживает а nios ненашел. зато на сайте автора плисин есть дистрибутивы тулсов. оттуда чем не устраивает?

 

Мне не удалось собрать ими что либо... я железячник, а не программист - мне тяжело разобраться как ими пользоваться. они отличаются от стандартного GCC.

[Spym 0]

klen, смотрите, какая штука:

 

test.cpp
arm-kgp-eabi-g++ -c  -mcpu=arm7tdmi-s  -gdwarf-2   -O0 -Wall -Wcast-align -Wimplicit -Wpointer-arith -Wswitch -Wreturn-type -Wunused -Wa,-adhlns=./tmp/test.lst  -funsigned-char -ffunction-sections -fdata-sections  -MD -MP -MF ./tmp/test.o.d
-std=c++0x test.cpp -o test.o
cc1plus.exe: warning: command line option '-Wimplicit' is valid for C/ObjC but not for C++ [enabled by default]
test.cpp:28:11: internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'integer_cst' in decl_linkage, at cp/tree.c:2969
Please submit a full bug report,
with preprocessed source if appropriate.
See <[email protected]> for instructions.
make: *** [test.o] Error 1

 

Это мне захотелось проверить шаблон, где аргументом по умолчанию будет NULL. Разумеется, такой шаблон компилироваться отказался, но дело и не в нём.

Вот весь test.cpp:

 

#include <cstdlib>

volatile int i = 0;

void my_callee()
{
    i++;
    return;
}

//void null_callee() { }
//static void(*const NULL_CALLEE)() = null_callee;
static void(*const NULL_CALLEE)() = static_cast<void(*const)()>(NULL);


template < int Smth, void(*Callee)() = NULL_CALLEE >
class TCaller
{
public:
    static void Invoke()
    {
        Callee();
    }
};


//TCaller<-2, my_callee> ct;
TCaller<-1> ct;

int main()
{
    ct.Invoke();
    return 0;
}

 

Версия, правда, не самая последняя (win32):

C:\kgp_arm_eabi\bin>arm-kgp-eabi-c++ --version
arm-kgp-eabi-c++ (Klen's GCC package (KGP) for ARM/elf platform, ---- HALLOWEEN EDITIION 2010 ---- ) 4.6.0 20101030 (exp
erimental)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 

P.S. не могу еще раз не обратить Вашего внимания на старый вопрос, уже утративший актуальность в связи с переходом на KGP, но не оставивший моего любопытства: http://electronix.ru/forum/index.php?showtopic=82874 - ни здесь, ни на ЛОРе никто на него не ответил, что несколько странно.

[klen 1]

свежак

теперь мы будем дрюкать код компиллером версии 4.7.X

 

mingw64

http://klen.org/Files/DevTools/x86-64_kgp-...w32_20110327.7z

 

arm

http://klen.org/Files/DevTools/kgp-arm-eab...-64_20110327.7z

есть возможность собирать с поддержкой процов Faraday http://www.faraday-tech.com/html/products/...technology.html, оно комунить нуна? почитал доки и не впечатлился...

mips

http://klen.org/Files/DevTools/x86-64_kgp-...w32_20110327.7z

 

первые два протестерованы на текущих проектах

, последний нечем тестить.

 

 

[gopher 0]

arm

http://klen.org/Files/DevTools/kgp-arm-eab...-64_20110327.7z

а можно kgp-arm-eabi еще и под x86 ?