Перейти к содержанию
    

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

либо ... ну и как обычно... под винду все работант через жЁпу... классика....

Косяк явно не в нем, ибо нашел вчера лекарство от этой баги. Итак, исходное выражение вот такого вида:

 

_settings_start_flash = _etext + _data_end - _data_start;

 

Считается не правильно, но если его переписать так:

 

_settings_start_flash = _etext + (_data_end - _data_start);

 

то все считается верно :1111493779: То же самое происходит с последней версией с launchpad.net . В древнем CodeSourcery (gcc4.4) все работает нормально. Скрипт приложил (в варианте со скобками и без :)), также как и два .map файла (один без скобок,с багом, второй со скобками).

 

Со скобками вчера все нормально слинковалось и работает :) Код получился на 1.5% меньше, чем в версии 4.4, по быстродействию не смотрел.

main.7z

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

_settings_start_flash = _etext + _data_end - _data_start;

Считается не правильно, но если его переписать так:

_settings_start_flash = _etext + (_data_end - _data_start);

то все считается верно

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

пока только ощущения: типизацию в ld-script добавили? Или она возникла неожиданно...

В скрипте от arm.com используются такие выражения (мой сделан на основе их образца):

 

 

 

__etext = .;

 

.data : AT (__etext)

{

__data_start__ = .;

*(vtable)

*(.data*)

...

__data_end__ = .;

 

} > DTCM

 

PROVIDE(__icm_start__ = ORIGIN(ITCM));

PROVIDE(__icm_end__ = ORIGIN(ITCM) + LENGTH(ITCM));

 

PROVIDE(__dtm_start__ = ORIGIN(DTCM));

PROVIDE(__dtm_end__ = ORIGIN(DTCM) + LENGTH(DTCM));

 

Изменено пользователем Genadi Zawidowski

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Считается не правильно, но если его переписать так:
Вот охота вам вручную все это суммировать...

.data  :
    {
..............
    } >RAM > AT ROM 

    .settings  :
    {
.............. 
    } >RAM

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

В скрипте от arm.com используются такие выражения (мой сделан на основе их образца):

Когда складываете-вычитаете только два адреса, то все ок. У Вас их как раз два (да и в 99.99% скриптов наверное тоже так).

 

Вот охота вам вручную все это суммировать...

Можно было и примерно так сделать, а потом через LOADADDR() определить адреса загрузки, но вопрос собственно был не в этом, да и не всегда так сделать выйдет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

работы на хранилище....

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

работы на хранилище....

 

все востановлено. архив работает.

 

свежак хост x86_64 linux

www.klen.org/Files/DevTools/x86_64-kgp-linux-gnu/arm-kgp-eabi_@_x86_64-kgp-linux-gnu_20151023_MENTHA.7z

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

свежак хост x86_64 linux

www.klen.org/Files/DevTools/x86_64-kgp-linux-gnu/arm-kgp-eabi_@_x86_64-kgp-linux-gnu_20151030_ELYTRIGIA.7z

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

собираю проект на chibios (stable 2.6.x) под чип LPC11U68 (cortex-m0).

проект собирается и работает пока не используется деление.

Целочисленное деление улетает в hard fault.

код где падает:

0000222c <____aeabi_uidiv_from_thumb>:
    222c:    4778          bx    pc
    222e:    46c0          nop    ; (mov r8, r8)
    2230:    eaffffa6     b    20d0 <__aeabi_uidiv>   <<<--------- здесь возникает hard fault

 

отладчик тоже не понимает команду b 20d0

          ____aeabi_uidiv_from_thumb:
0000222c:   bx pc
0000222e:   nop; (mov r8, r8)
00002230:  ; <UNDEFINED> instruction: 0xffa6eaff

 

компилятор

gcc version 6.0.0 20150726 (experimental) (Klen's GNU package (KGP) for x86_64-kgp-linux-gnu platform. << CONVOLVULUS >>)

 

ключи компиляции

/opt/kgp-arm/bin/arm-kgp-eabi-gcc -c -mcpu=cortex-m0 -O1 -ggdb -fomit-frame-pointer -mfloat-abi=soft -mlittle-endian -mtune=cortex-m0plus -Wall -Wextra -Wstrict-prototypes -Wa,-alms=build/lst/hal_lld.lst -DLPC11U68 -D__NEWLIB__ -DCORE_M0PLUS -DCORTEX_USE_FPU=FALSE -DTHUMB_PRESENT -mno-thumb-interwork -DTHUMB_NO_INTERWORKING -MD -MP -MF .dep/hal_lld.o.d -mthumb -DTHUMB

 

если использовать компилятор devkitARM gcc version 4.9.2 (devkitARM release 44) результат такой же.

 

 

===============

провел сравнение разных компиляторов (исходники и makrfile без изменений):

devkitARM_r41 (gcc-4.7.1) - работает с -mcpu=cortex-m0 , не поддерживает cortex-m0plus

devkitARM_r42 (gcc-4.8.2) - работает с -mcpu=cortex-m0 , не работает c -mcpu=cortex-m0plus

 

devkitARM_r43 (gcc-4.9.2) - не работает c -mcpu=cortex-m0 , не работает c -mcpu=cortex-m0plus

devkitARM_r44 (gcc-4.9.2) - не работает c -mcpu=cortex-m0 , не работает c -mcpu=cortex-m0plus

arm-kgp-eabi-gcc (gcc-6.0.0) - не работает c -mcpu=cortex-m0 , не работает c -mcpu=cortex-m0plus

 

-mtune=cortex-m0plus влияния не оказывает

 

проверить просто: если в дизассемблерном листинге появляется ересь вида

000023c0 <____aeabi_idiv0_from_arm>:
    23c0:    e59fc000     ldr    ip, [pc]; 23c8 <____aeabi_idiv0_from_arm+0x8>
    23c4:    e12fff1c     bx    ip
    23c8:    000022f1     .word    0x000022f1

000023cc <____aeabi_uidiv_from_thumb>:
    23cc:    4778          bx    pc
    23ce:    46c0          nop        ; (mov r8, r8)
    23d0:    eaffff7e     b    21d0 <__aeabi_uidiv>
    ...

работать не будет

 

Изменено пользователем _3m

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

это все интересно и с этим нужно разобратся.

я как раз допилил свой сдк еще и под М0, первая примитивная прграмка завелась на STM32F030

деление не втыкал, теперь посмотрю.

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

подтверждаю косяг. есть идеи как поправить - буду пробывать.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

починил. добавил таргет специально для m0, штатном варианте из транка компиллер знает что у процесора набор команд tрumb2, но линкеру передает либы с таргетам в которм инструкции tрumb1, что как мы убедились приводит к выташниваю декодера команд ЦПУ.... его реакция ожидаема - "моя твоя команды непонимать"...

 

использовались для теста значимые по ключики для нашего сдучая

-std=c++14 -D__CORTEX_M0__ -D__STM32F030F4P6__ -DSTM32F030x6 -D__STM32F0XX__ -DARM_MATH_CM0 -mcpu=cortex-m0 -mfloat-abi=soft -mthumb -Ofast -fomit-frame-pointer -finline-functions -ffunction-sections -fdata-sections -fgraphite -funroll-loops -flto=8 -ffat-lto-objects ...... и так дале проектоспецефичное

исходник для теста

#include "appdefs.h"

volatile int8_t a8 = 8;
volatile int8_t b8 = 3;

volatile int16_t a16 = 8;
volatile int16_t b16 = 3;

volatile int32_t a32 = 8;
volatile int32_t b32 = 3;

volatile int64_t a64 = 4000000000;
volatile int64_t b64 = 3;


int main(void)
{

 while (1)
{
  NOP();
  NOP();
  a8 = (a8 * b8) / ( a8 - b8 );
  NOP();
  a16 = (a16 * b16) / ( a16 - b16 );
  NOP();
  a32 = (a32 * b8) / ( a32 - b32 );
  NOP();
  a64 = (a64 * b64) / ( a64 - b64 );
  NOP();
}
}

код из под компилятора кому интересно

int main(void)
{

 while (1)
{
  NOP();
8000366:	1c00		  adds	r0, r0, #0
  NOP();
8000368:	1c00		  adds	r0, r0, #0
  a8 = (a8 * b8) / ( a8 - b8 );
800036a:	465e		  mov	r6, fp
800036c:	4a41		  ldr	r2, [pc, #260]; (8000474 <ResetHandler+0x3b4>)
800036e:	4c41		  ldr	r4, [pc, #260]; (8000474 <ResetHandler+0x3b4>)
8000370:	7830		  ldrb	r0, [r6, #0]
8000372:	7813		  ldrb	r3, [r2, #0]
8000374:	7837		  ldrb	r7, [r6, #0]
8000376:	7826		  ldrb	r6, [r4, #0]
8000378:	b241		  sxtb	r1, r0
800037a:	b27a		  sxtb	r2, r7
800037c:	b258		  sxtb	r0, r3
800037e:	b273		  sxtb	r3, r6
8000380:	4348		  muls	r0, r1
8000382:	1ad1		  subs	r1, r2, r3
8000384:	f000 f9e2 	bl	800074c <__aeabi_idiv>
8000388:	465d		  mov	r5, fp
800038a:	b2c0		  uxtb	r0, r0
800038c:	7028		  strb	r0, [r5, #0]
  NOP();
800038e:	1c00		  adds	r0, r0, #0
  a16 = (a16 * b16) / ( a16 - b16 );
8000390:	4f39		  ldr	r7, [pc, #228]; (8000478 <ResetHandler+0x3b8>)
8000392:	4e3a		  ldr	r6, [pc, #232]; (800047c <ResetHandler+0x3bc>)
8000394:	4938		  ldr	r1, [pc, #224]; (8000478 <ResetHandler+0x3b8>)
8000396:	4a39		  ldr	r2, [pc, #228]; (800047c <ResetHandler+0x3bc>)
8000398:	883c		  ldrh	r4, [r7, #0]
800039a:	8833		  ldrh	r3, [r6, #0]
800039c:	880d		  ldrh	r5, [r1, #0]
800039e:	8817		  ldrh	r7, [r2, #0]
80003a0:	b224		  sxth	r4, r4
80003a2:	b218		  sxth	r0, r3
80003a4:	b22e		  sxth	r6, r5
80003a6:	b23b		  sxth	r3, r7
80003a8:	1af1		  subs	r1, r6, r3
80003aa:	4360		  muls	r0, r4
80003ac:	f000 f9ce 	bl	800074c <__aeabi_idiv>
80003b0:	4931		  ldr	r1, [pc, #196]; (8000478 <ResetHandler+0x3b8>)
80003b2:	b280		  uxth	r0, r0
80003b4:	8008		  strh	r0, [r1, #0]
  NOP();
80003b6:	1c00		  adds	r0, r0, #0
  a32 = (a32 * b8) / ( a32 - b32 );
80003b8:	4642		  mov	r2, r8
80003ba:	4d2e		  ldr	r5, [pc, #184]; (8000474 <ResetHandler+0x3b4>)
80003bc:	4e30		  ldr	r6, [pc, #192]; (8000480 <ResetHandler+0x3c0>)
80003be:	782f		  ldrb	r7, [r5, #0]
80003c0:	6810		  ldr	r0, [r2, #0]
80003c2:	6814		  ldr	r4, [r2, #0]
80003c4:	6831		  ldr	r1, [r6, #0]
80003c6:	b27b		  sxtb	r3, r7
80003c8:	4358		  muls	r0, r3
80003ca:	1a61		  subs	r1, r4, r1
80003cc:	f000 f9be 	bl	800074c <__aeabi_idiv>
80003d0:	4645		  mov	r5, r8
80003d2:	6028		  str	r0, [r5, #0]
  NOP();
80003d4:	1c00		  adds	r0, r0, #0
  a64 = (a64 * b64) / ( a64 - b64 );
80003d6:	4657		  mov	r7, sl
80003d8:	4648		  mov	r0, r9
80003da:	464c		  mov	r4, r9
80003dc:	6841		  ldr	r1, [r0, #4]
80003de:	6800		  ldr	r0, [r0, #0]
80003e0:	683a		  ldr	r2, [r7, #0]
80003e2:	687b		  ldr	r3, [r7, #4]
80003e4:	f000 fa38 	bl	8000858 <__aeabi_lmul>
80003e8:	6826		  ldr	r6, [r4, #0]
80003ea:	6867		  ldr	r7, [r4, #4]
80003ec:	4655		  mov	r5, sl
80003ee:	0032		  movs	r2, r6
80003f0:	682c		  ldr	r4, [r5, #0]
80003f2:	686d		  ldr	r5, [r5, #4]
80003f4:	003b		  movs	r3, r7
80003f6:	1b12		  subs	r2, r2, r4
80003f8:	41ab		  sbcs	r3, r5
80003fa:	f000 fa09 	bl	8000810 <__aeabi_ldivmod>
80003fe:	464a		  mov	r2, r9
8000400:	6010		  str	r0, [r2, #0]
8000402:	6051		  str	r1, [r2, #4]
  NOP();
8000404:	1c00		  adds	r0, r0, #0
8000406:	e03d		  b.n	8000484 <ResetHandler+0x3c4>

 

вот свежак с добавленным отдельным таргеом сортех-m0.

http://www.klen.org/Files/DevTools/x86_64-...03_CAMPANULA.7z

!!! ИСПРАВЛЕНО: архив похерен с связи с более свежей сборкой под темже именем, смотри следующее сообщение !!

 

есть еще возможность сделать отдельно еще для

cortex-m0.small-multiply

cortex-m0plus

cortex-m0plus.small-multiply

 

m0plus jn m0 по командам ничем не отличается - поэтому можно кормить также . отдельно заведено в связи с тем что разный конвеер и оптимизатор по разному планирует поток инструкций выжимая из онвеера скорость. код совместимый.

 

по ядрам cortex-m0.small-multiply и cortex-m0plus.small-multiply . это про то что есть модификация с вырезанным модулем умножения. цитата:

Some configurations of the Cortex-M0 and Cortex-M1 come with a high latency

multiplier. Small multiplier means using add/sub/shift instructions to replace the mul

instruction for the MCU that has no fast multiplier.

 

под это ну уж совсем говноЦПУ я добавлю в сборку поддерку в следующий раз.

внимание!!! если собрать текущей сборкрй с ключиками cortex-m0 то нагенерятся умножения которых в цпу cortex-m0.small-multiply нет, и будет как облом. нада подождать до следующей сборки или отнести на помойку микросхемку.

 

to _3m

попробуье свежак с ключем -mcpu=cortex-m0, должно звзлететь. как сказал выше cortex-m0здгы протяну пожже.

 

решил отныне собирать компиллер с поддержкой русского языка, у кого линукс с русской локалью - будет матом ругатся а не по аглицки! это мои ответные НАТО санкции :)

Изменено пользователем klen
[codebox] для длинного кода, [code] - для короткого!!!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

раз уж пошла такая пьянка - разом решил протянуть и cortex-m0plus.

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

 

 

 

http://klen.org/Files/DevTools/x86_64-kgp-...04_CAMPANULA.7z

 

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

 

для сборка cortex-m0 и cortex-m0plus кода, необходимо воткнуть ключики -mcpu=cortex-m0 или -mcpu=cortex-m0plus соответственно, будет генерится специфичный для оных конвейеров код( набор команд один но конвейер в первом случае 3-ступенчатый во втром 2 ступенчатый, поэтому есть различия на выходе ) и притянутся правильные либы.

 

таргеты

cortex-m0.small-multiply

cortex-m0plus.small-multiply

протяну в следующий раз если будут сообщения что с cortex-m0/m0plus все сложилось хорошо.

 

извращенцы котрые кодят кортексики под масдаем есть? собирать для венды64 сборку?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Извращенцы есть, за билд для win64

+1

Все не получается переползти на линь.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...