[AHTOXA 15]

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

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

Ну вот тот самый тестовый пример, который я постил. Вот что на него говорит openocd:

Error: No flash at address 0x07fff000

Error: address range 0x08000644 .. 0x080007ff is not sector-aligned

Command handler execution failed

openocd пробовал и из этой сборки, и прошлый, точно рабочий.

[Ash_snz 0]

чето я попутол все.... действительно R3000

А не попадался ли какой мануал на тему - сборка с лонгджампами и без для чайников?

 

[klen 1]

Ну вот тот самый тестовый пример, который я постил. Вот что на него говорит openocd:

openocd пробовал и из этой сборки, и прошлый, точно рабочий.

 

понятно. я посотрел под отладчиком как gold секциизакидывает в регионы памяти - у мня эта цифра тоже была. видимо это глюк локальный. пока могу предложить в папках bin /arm-kgp-eabi/bin поменять ld чтоб он указывал на ld.bfd а не ld.gold. По умолчанию в моей сборке при линковке используется голд, с обыным ld я разниы не заметил но голд преспективнее и наверно быстрее.

 

2_Ash_snz

с longcall ( longjump - это из другой оперы - переключение контекста в проге ) нет никаких хитростей. если неставить компилеру -mlong-calls то он пытается сделать короткий вызов - если адрес можно заменить смещением и даже самим адресом функции - это экономит такты проца, если воткнуть -mlong-calls то тогда адрес вычисляется впихивается в регистр и уже тогда вызываетя функция. можно непосдедственно управлять вызовом функции обявляя ее например

void __attribute__ ((long_call)) foo()

{

.......

}

такая функция будет вызыватся длинно.

также модно назначить блоку кода эту опцию

#pragma long_calls

.....any code with func long calls method...

#pragma no_long_calls

 

вот ссылка на ликбез http://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc.pdf

 

 

 

 

[Aaron 1]

2_Aaron

".. точка входа в libstdc++ ..." это известная мне ситуация. дело в том что периодически меняется интерфейс libcstdc++ и тогда если компилятор пытается грузануть libcstdc++.dll(.so) не той версии (например если установлена еще и другая версия компилера)- например из за косяков с путями и тд - то он естественно отвалится. в дистрибутиве который я выкладываю всегда есть эти либы в /lib /lib64 для сошек, dll'ки всегда лежат в /bin вместе с бинарниками.

Да, действительно. Нашлась ещё такая библиотека в mingw, а он у меня в path раньше прописан, чем kgp :) значит просто до этого повезло и бинарный интерфейс библиотеки mingw и kgp совпадал!

[AHTOXA 15]

видимо это глюк локальный. пока могу предложить в папках bin /arm-kgp-eabi/bin поменять ld чтоб он указывал на ld.bfd а не ld.gold.

Да, точно, так заработало. (Кстати, там не линки, а прямо копии были).

С LTO правда что-то не то выходит:

__________text data bss dec hex

без LTO: 13312 52 7448 20812 514c

__с LTO: 15616 36 19796 35448 8a78

Видимо, так и есть, какой-то локальный косяг.

 

Ув. klen, а не могли бы вы собрать для всех здесь что-нибудь стабильное? Типа, "4.6.0 RC", или что-то вроде того? Такая просьба здесь уже звучала, но видимо подзабылась уже. Дело в том, быть "на острие" и тестировать новые сборки безусловно приятно и интересно, но иногда надо на чём-то работать:) Хочется в таких случаях иметь что-то понадёжнее.

Пожалуйста! :santa2:

 

[Ash_snz 0]

2_Ash_snz

с longcall ( longjump - это из другой оперы - переключение контекста в проге ) нет никаких хитростей. если неставить компилеру -mlong-calls то он пытается сделать короткий вызов ...method...

#pragma no_long_calls

 

вот ссылка на ликбез http://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc.pdf

В мэйкфайле лонгкол стоит. Мы его туда даже довольно давно затолкали оказывается. Т.е. получается что моя прога вроде как с лонгколами идет. а вот траблы возникают при попытках _errno в оперативу запихать. Ятак понимаю, это кусок матем библ., при том стандартной. Ни кто не владеет информацией - куда должен указывать этот символ(_errno) в ОЗУ или ПЗУ?

А не понадобиться ли пересобирать libm с long-call для этого дела?

 

и абсолютно такая же непонятка с global pointer - _gp - тоже ничего про него не знаю :( описания какие-то вялые везде.

 

зы. сейчас использую memcpy для копирования инициализированных переменных (образа памяти) в ОЗУ. начинает работать лучше и лучше. Вот только выяснил нахождение глобальных переменных, но не локальных. Локальные в областсях .data? почему-то ни objdump ни readelf ни при создании карты (-М) не показывается где они живут.

 

[ReAl 0]

Ув. klen, а не могли бы вы собрать для всех здесь что-нибудь стабильное? Типа, "4.6.0 RC", или что-то вроде того? Такая просьба здесь уже звучала, но видимо подзабылась уже. Дело в том, быть "на острие" и тестировать новые сборки безусловно приятно и интересно, но иногда надо на чём-то работать:) Хочется в таких случаях иметь что-то понадёжнее.

А ещё бы со статической линковкой библиотек... И для AVR тоже стабильную...

 

 

[klen 1]

А ещё бы со статической линковкой библиотек... И для AVR тоже стабильную...

 

могу.

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

 

можно сделать сборку из релизов :

binutils 2.21

gcc 4.6.2

gdb 7.3.1

newlib 1.19.0

openocd 0.5.0

 

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

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

mips-вой сборкой кто пользуется?

[AHTOXA 15]

могу.

встречный вопрос - а как вы измерили что то что я выкладываю нестабильно?

Я про все найденные проблемы рапортую прямо здесь. Но я тестирую не каждый свежак.

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

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

Ну есть же у них какие-то стабильные отсечки? Альфа, бета, релиз-кандидат, релиз, релиз с исправлениями... Вот чтоб не ниже уровня релиз-кандидата:)

[ReAl 0]

могу.

встречный вопрос - а как вы измерили что то что я выкладываю нестабильно?

Меня до сих пор больше AVR интересует.

Но вот из этого

http://electronix.ru/forum/index.php?showt...mp;#entry961742

у меня сборка AVR так и не заработала

http://electronix.ru/forum/index.php?showt...mp;#entry962552

 

Подбрасывал библиотеки из соседнего архива, вроде запустилось, но ругнулось на отсутствие ldscripts, подбросил их из предыдущей сборки, которую иногда запускаю (кажется, ещё от мая 2010) — начал падать ld.

Нюансов не помню, это на работе нужно опять смотреть и вспоминать.

Библиотеки не кешировал, запускаю с LD_LIBRARYPATH=чего_надо перед именем исполняемого бинарника.

http://electronix.ru/forum/index.php?showt...mp;#entry962230

(ну там может не lib, а lib64, по месту смотрел что надо)

С кешированием у меня ещё на сборках 2010 года потом вылазила проблема с каким-то другим софтом, с тех пор и не пробовал.

Потому и попросил статическую сборку.

 

Предыдущая сборка AVR и какая-то из более свежих ARM-овских так вполне работают.

 

Дома у меня сейчас на dell-овском ноуте убунта 10.04 32-битная (стояла на нём с завода, не менял), так что родным убунтячьим avr-gcc пользуюсь.

[klen 1]

ок. соберм из релизов. но что получится из этого нам пока не известно :)

[ARV 0]

ок. соберм из релизов. но что получится из этого нам пока не известно :)

и, если можно, снизойдите до 32-битного варианта тоже...

[Ash_snz 0]

mips-вой сборкой кто пользуется?

Мипсовой мы пользуемся... немножко особенной только :)

 

[klen 1]

сборка хост x86_32 таргет ARM

http:///klen.org/Files/DevTools/x86_32-kgp-mingw/arm-kgp-eabi-x86_32-20111120.7z

собрано из релизных

binutils-2.21.1

gcc-4.6.2

gdb-7.3.1

 

не тестил - неначем, нет 32 битного масдая

[GenaSPB 11]

Потестил:

 

Сегодняшняя:

 

с ключём -flto:

 

C:\user\dds2\TC1\at91sam7s>make

arm-kgp-eabi-gcc ../crt_sam7s.o ../cp15_asm.o ../bandfilters.o ../board.o ../sequen.o ../encoder.o ../hardware.o ../hd44780.o ../dis

play.o ../keyboard.o ../keymaps.o ../nvram.o ../spifuncs.o ../formats.o ../synthcalcs.o ../uc1601s_small.o ../uc1601s_font.o ../uc16

01s_font_alt.o ../uc1601s.o ../twi.o ../tc1.o -mcpu=arm7tdmi -flto -Os -nostartfiles -T../sam7x64_rom.ld -Wl,-Map=tc1_rom.map,--cref

,--no-warn-mismatch -lm -o tc1_rom.elf

c:/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.2/../../../../arm-kgp-eabi/bin/ld.exe: cannot find -lugin

c:/kgp_arm_eabi/bin/../libexec/gcc/arm-kgp-eabi/4.6.2/liblto_plugin-0.dll: file not recognized: File format not recognized

collect2: ld returned 1 exit status

make.EXE: *** [tc1_rom.elf] Error 1

 

Без ключа -flto:

 

arm-kgp-eabi-gcc ../crt_sam7s.o ../cp15_asm.o ../bandfilters.o ../board.o ../sequen.o ../encoder.o ../hardware.o ../hd44780.o ../dis

play.o ../keyboard.o ../keymaps.o ../nvram.o ../spifuncs.o ../formats.o ../synthcalcs.o ../uc1601s_small.o ../uc1601s_font.o ../uc16

01s_font_alt.o ../uc1601s.o ../twi.o ../tc1.o -mcpu=arm7tdmi -Os -nostartfiles -T../sam7x64_rom.ld -Wl,-Map=tc1_rom.map,--cref,--no

-warn-mismatch -lm -o tc1_rom.elf

c:/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.2/../../../../arm-kgp-eabi/bin/ld.exe: cannot find -lgcc

collect2: ld returned 1 exit status

make.EXE: *** [tc1_rom.elf] Error 1

 

 

Первая сборка их тех, где появился -flto:

 

Без ключа -flto:

 

arm-kgp-eabi-gcc ../crt_sam7s.o ../cp15_asm.o ../bandfilters.o ../board.o ../sequen.o ../encoder.o ../hardware.o ../hd44780.o ../dis

play.o ../keyboard.o ../keymaps.o ../nvram.o ../spifuncs.o ../formats.o ../synthcalcs.o ../uc1601s_small.o ../uc1601s_font.o ../uc16

01s_font_alt.o ../uc1601s.o ../twi.o ../tc1.o -mcpu=arm7tdmi -Os -nostartfiles -T../sam7x64_rom.ld -Wl,-Map=tc1_rom.map,--cref,--no

-warn-mismatch -lm -o tc1_rom.elf

arm-kgp-eabi-size tc1_rom.elf

text data bss dec hex filename

36776 244 2192 39212 992c tc1_rom.elf

 

с ключём -flto:

 

arm-kgp-eabi-gcc ../crt_sam7s.o ../cp15_asm.o ../bandfilters.o ../board.o ../sequen.o ../encoder.o ../hardware.o ../hd44780.o ../dis

play.o ../keyboard.o ../keymaps.o ../nvram.o ../spifuncs.o ../formats.o ../synthcalcs.o ../uc1601s_small.o ../uc1601s_font.o ../uc16

01s_font_alt.o ../uc1601s.o ../twi.o ../tc1.o -mcpu=arm7tdmi -flto -Os -nostartfiles -T../sam7x64_rom.ld -Wl,-Map=tc1_rom.map,--cref

,--no-warn-mismatch -lm -o tc1_rom.elf

arm-kgp-eabi-size tc1_rom.elf

text data bss dec hex filename

35736 244 2184 38164 9514 tc1_rom.elf