scmRTOS & MSPGCC. Ошибка компиляции примеров Опции

[aliko]

Под линукс в mspgcc4 (gcc-4.4.5) и 3я и 4я версии ОС при компиляции выдают следующее:

--- assembling ../scmRTOS/MSP430/OS_Target_asm.S...
../scmRTOS/MSP430/OS_Target_asm.S: Assembler messages:
../scmRTOS/MSP430/OS_Target_asm.S:125: Error: unknown opcode `vector_(11'

Аналогично ругается mspgcc (20110716) под виндовс.

Кстати поясните пожалуйста в чем цимус существования двух версий - mspgcc и mspgcc4. Вторая вроде как заявляет что она хороша тем что базируется на 4й версии GCC, однако обычный mspgcc тоже вроде как на четвертой и даже на 4.5 против 4.4 у mspgcc4?

Сообщение отредактировал aliko - Jul 26 2011, 19:01

[AHTOXA]

Ух, что-то они всё поменяли... Я в отпуске, сходу не разобрался
Как теперь объявлять обработчик прерывания в ассемблерном файле?

Кстати поясните пожалуйста в чем цимус существования двух версий - mspgcc и mspgcc4.

Насколько я понял, изначально разработчики mspgcc не хотели переходить на GCC 4, поэтому отпочковался проект mspgcc4. А теперь видимо передумали, вот и получились два таких проекта

[MrYuran]

Насколько я понял, изначально разработчики mspgcc не хотели переходить на GCC 4, поэтому отпочковался проект mspgcc4. А теперь видимо передумали, вот и получились два таких проекта

Обана! А мужики-то не знают...
Надо попробовать.

[aliko]

Ух, что-то они всё поменяли... Я в отпуске, сходу не разобрался
Как теперь объявлять обработчик прерывания в ассемблерном файле?

Пока что пользуюсь mspgcc4 под виндовс, только он нормально компилит 3ю версию ОС. С 4й тоже не справляется.
Почему-то не работают объявления портов вида portN.out.pinN при их изменении ничего не происходит, приходится пользоваться объявлениями вида PNOUT. Кроме того заметил что в последних mspgcc убрали кучу заголовочных файлов типа iostructures.h, adc.h в которых были удобные структурки для работы с регистрами. Кроме того последний mspgcc ругается на включения файла "io.h" который уже депрекейтед и вместо него предлагает включать msp430.h. Вобщем с компиляторами GCC зоопарк.

[MrYuran]

Почему-то не работают объявления портов вида portN.out.pinN при их изменении ничего не происходит

Это была примочка divil'а, видимо решили её выкинуть.
Кстати, я с ней основательно накололся, не советую использовать.
Почему-то иногда игнорирует __attribute__((packed)), с которым объявлены структуры портов, и в случае выравнивания по границе слова начинается дурдом...

Я немного доработал макросы Аскольда Волкова (ещё не совсем до конца), получается не хуже, но главное - 100% предсказуемо.

CODE

#include "_useful_gpio.h" // Макросы Аскольда Волкова

#define SYS_WDT P4,7,H
#define PWR_WDT P6,0,H

static __inline__ void WatchDogInit(void)
{
InitAsOut(PWR_WDT);

InitAsOut(SYS_WDT);
}

static __inline__ void ClearWatchDog(void)
{
toggle_pin(SYS_WDT);
}

static __inline__ void ClearPWRWatchDog(void)
{
toggle_pin(PWR_WDT);
}

Кроме того последний mspgcc ругается на включения файла "io.h" который уже депрекейтед и вместо него предлагает включать msp430.h. Вобщем с компиляторами GCC зоопарк.

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

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

[aliko]

Я немного доработал макросы Аскольда Волкова (ещё не совсем до конца), получается не хуже, но главное - 100% предсказуемо.

А можно поподробнее про эти макросы?

что-то типа такого?

Код

#define P_PWR   4,7,0

#define port_on(TRIPLE) xport_on(TRIPLE)
#define xport_on(PORT, PIN, ONSTATE) (ONSTATE ? P##PORT##OUT |= BIT##PIN : P##PORT##OUT &= ~BIT##PIN)

#define port_off(TRIPLE) xport_off(TRIPLE)
#define xport_off(PORT, PIN, ONSTATE) (!ONSTATE ? P##PORT##OUT |= BIT##PIN : P##PORT##OUT &= ~BIT##PIN)

использовать:

Код

port_on(P_PWR);
port_off(P_PWR);

[MrYuran]

А можно поподробнее про эти макросы?

что-то типа такого?

Да, только я ещё инициализацию добавил. Правда, ещё пока не до конца получилось то, что задумывал.

[AHTOXA]

А можно поподробнее про эти макросы?

Вот они:  macros.h.zip ( 731 байт ) Кол-во скачиваний: 100

Или, если уж мы в ветке про scmRTOS, то гляньте на этот вариант.

[AHTOXA]

Под линукс в mspgcc4 (gcc-4.4.5) и 3я и 4я версии ОС при компиляции выдают следующее:

Скачал mspgcc-20110716, поправил ось. Теперь всё компилируется, но при линковке не находит -lstdc++. Похоже мне достался какой-то кривоватый msp-gcc:)
Приаттачиваю исправленный вариант, попробуйте его у себя. Если заработает, я закоммичу исправления.
 scmRTOS_4_MSP.zip ( 38.53 килобайт ) Кол-во скачиваний: 101

[aliko]

Приаттачиваю исправленный вариант, попробуйте его у себя. Если заработает, я закоммичу исправления.
 scmRTOS_4_MSP.zip ( 38.53 килобайт ) Кол-во скачиваний: 101

Попробовать под линукс смогу только дома, на работе стоит винда. Виндовский mingw32-make не дружит почему-то с мейкфалом для 4й версии ОС, поэтому я перенес Ваши исправления в 3ю версию и она нормально откомпилировалась с новой версией mspgcc-20110716.

Кстати, не подскажите как заставить виндовский make нормально выполнять clean? Не силен в написании мейкфалов, но он ругается по всей видимости на отсутствие rm а когда заменяю его на del то продолжает ругаться на "Missing separator". Может ему не нравятся слеши "/" вместо виндовских "\"? Только вручную их все менять во всем файле как-то муторно выходит...

[MrYuran]

Кстати, не подскажите как заставить виндовский make нормально выполнять clean? Не силен в написании мейкфалов, но он ругается по всей видимости на отсутствие rm а когда заменяю его на del то продолжает ругаться на "Missing separator". Может ему не нравятся слеши "/" вместо виндовских "\"? Только вручную их все менять во всем файле как-то муторно выходит...

Код

# Очистка
RM = del

clean:
    - $(RM) $(obj_path)\*.o
    - $(RM) $(lst_path)\*.lst

[aliko]

Код

# Очистка
RM = del

clean:
    - $(RM) $(obj_path)\*.o
    - $(RM) $(lst_path)\*.lst

Оказалось что ошибка missing separator возникает когда строка начинаются с пробела вместо ТАБа, а мой редактор заменял табы пробелами, то вовсе не устраивало GNU-шный make.

[AHTOXA]

Оказалось что ошибка missing separator возникает когда строка начинаются с пробела вместо ТАБа, а мой редактор заменял табы пробелами, то вовсе не устраивало GNU-шный make.

А, ну тогда понятно. А то я всё не мог понять, какая разница между мейкфайлами от 4й и 3й версий

Попробуйте всё же собрать 4ю версию, мне интересно, это у меня что-то криво установилось, или ещё что-то.

[aliko]

Попробуйте всё же собрать 4ю версию, мне интересно, это у меня что-то криво установилось, или ещё что-то.

У меня вышла аналогичная ошибка линковщика (libstdc++) в линуксе при использовании mspgcc20110716. Однако mspgcc4 под линукс нормально собрал ваш проект. Также как я уже писал под виндовс в mspgcc20110716 проект собирается тоже отлично (правда тут я пробовал 3ю версию ОС с перенесенными туда вашими исправлениями, так как мейкфайл 4й версии много ругается и отказывается собирать проект под виндовс). Ну а что касается mspgcc4 под виндовс то она прекрасно компилирует 3ю версию ОС из репозитария, но очевидно в скором будущем тоже перестанет так как под линуксом последняя сборка mspgcc4 и mspgcc20110716 ведут себя уже одинаково, разве что последней не хватает libstdc++ при линковке. Кстати, на сайте mspgcc говорится следующее: From the GNU Compiler Collection (gcc) we have ported the C compiler (C++ without libstdc++). Однако в сборке под виндовс все работает хорошо. Также в mspgcc4 под линукс есть эта библиотека в папке lib.

Вобщем путаница пока еще та.

Я прилагаю исправленную версию ОС 3й версии, может быть имеет смысл перенести исправления из нее в ветку 3й версии. Она собирается как последней версией компилятора mspgcc20110716, так и по всей видимости более устаревшей сборкой mspgcc4(виндовс). Для этого я следующим образом изменил процедуру подключения заголовочных фалов:

Код

#if __GNUC_MINOR__ < 5
#include <io.h>
#include <signal.h>
#else
#include <legacymsp430.h>
#endif

А, ну тогда понятно. А то я всё не мог понять, какая разница между мейкфайлами от 4й и 3й версий

Ошибка была в мейкфайле 3й версии у меня. Мейкфайл 4й версии под виндовс ругается сильно и много и к сожалению даже не пишет какая строка иходного файла вызывет ошибку так что отлаживать его довольно проблематично.
Сообщения имеют следющий вид:

Ошибка в синтаксисе команды.
Ошибка в синтаксисе команды.
Ошибка в синтаксисе команды.
Ошибка в синтаксисе команды.
--- compiling ./src/main.cpp...
./src/main.cpp:155:1: fatal error: opening dependency file obj/main.d: No such file or directory
compilation terminated.
make: *** [obj/main.o] Error 1

Сообщение отредактировал aliko - Aug 2 2011, 08:49

Прикрепленные файлы

 scmRTOS_3_corrected.zip ( 26.57 килобайт ) Кол-во скачиваний: 9

 

[AHTOXA]

Кстати, на сайте mspgcc говорится следующее: From the GNU Compiler Collection (gcc) we have ported the C compiler (C++ without libstdc++). Однако в сборке под виндовс все работает хорошо.

Скорее всего вы ставили mspgcc20110716 поверх какой-то предыдущей, вот там и осталась эта библиотека. У меня её нет. (и в архиве mspgcc-20110716.zip её нет).
Победил это добавлением ключа линкера

Код

    LD_FLAGS    += -nostdlib

Только вот проверить результат сейчас не на чем.

Я прилагаю исправленную версию ОС 3й версии, может быть имеет смысл перенести исправления из нее в ветку 3й версии.

Третью версию договорились не трогать до выхода четвёртой. Потом может быть сделаю. А может и не надо станет

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

Поставьте решёточку перед строкой .SILENT - может прояснится. Скорее всего, ругается на mkdir. Попробуйте создать директории bak, obj, lst, exe вручную.

[aliko]

Победил это добавлением ключа линкера

Код

    LD_FLAGS    += -nostdlib

Перестают работать все стандартные библиотечные функции - memcpy, printf и т.д...
Какая-то пирова выходит победа к сожалению

Поставьте решёточку перед строкой .SILENT - может прояснится. Скорее всего, ругается на mkdir. Попробуйте создать директории bak, obj, lst, exe вручную.

Помогло. Действительно проблема была в создании катлогов.
Однако теперь 4я версия ОС при использовании mspgcc2011... под виндовс ругается на отсутствие libstdc++ аналогично линуксовской версии этого же компилятора, в то время как mspgcc4 собирает проект под виндовс отлично.
В то же время 3я версия ОС собирается без проблем любым компилятором и в любой ОС. ПОхоже все-таки где-то в мейкфайле надо копаться

[AHTOXA]

В то же время 3я версия ОС собирается без проблем любым компилятором и в любой ОС. ПОхоже все-таки где-то в мейкфайле надо копаться

Дык, просто поменяйте мейкфайл!

ЗЫ. Кстати, у меня не собралась и третья версия. Ругается:

ld.exe: unrecognised emulation mode: msp430x149
Supported emulations: msp430

[aliko]

Дык, просто поменяйте мейкфайл!

помогло

единственное что я добавил в мейкфайл от 3й версии - опцию -fno-threadsafe-statics иначе не собиралось, ну и -save-temps для удобства...

ЗЫ. Кстати, у меня не собралась и третья версия. Ругается:

странно, у меня теперь все работает с мейкфайлом от 3 версии

[AHTOXA]

Я разобрался, в чём отличие мейкфайлов. В мейкфайле от третьей версии в качестве линкера вызывается gcc, а в четвёртой версии - g++. Поменяв в мейкфайле от четвёртой версии
LD = $(TOOL)g++
на
LD = $(TOOL)gcc
, я смог скомпилировать четвёртую версию. Не знаю только, работоспособен ли результат, не на чем проверить сейчас.

[AHTOXA]

Проверил на небольшом проекте. Работает.
Расстроила пара моментов:
1. Зачем-то убрали удобные алиасы типа SSEL_ACLK, TASSEL_SMCLK, MC_CONT, и проч. Чем они мешали, непонятно.
2. Не работает с ключами компилера/линкера -ffunction-sections -fdata-sections / -gc-sections. Что-то лишнее выбрасывается. Надо разбираться со скриптами линкера, сейчас некогда.

[MrYuran]

2. Не работает с ключами компилера/линкера -ffunction-sections -fdata-sections / -gc-sections. Что-то лишнее выбрасывается. Надо разбираться со скриптами линкера, сейчас некогда.

Я попробовал свой проектик скомпилить, так у меня процентов 70 выкинуло, включая main()
Системы в действиях линкера не обнаружил.

[aliko]

2. Не работает с ключами компилера/линкера -ffunction-sections -fdata-sections / -gc-sections. Что-то лишнее выбрасывается. Надо разбираться со скриптами линкера, сейчас некогда.

А чем чревато отсутствие этих ключей? В мейкфале для 3й версии ОС их вроде и не было и все прекрасно без них пока что работает в моем проекте, который не так уж и мал...

[MrYuran]

А чем чревато отсутствие этих ключей?

Все функции и данные, которые есть в исходниках, окажутся в бинарнике, независимо от их использования/неиспользования.

[aliko]

Все функции и данные, которые есть в исходниках, окажутся в бинарнике, независимо от их использования/неиспользования.

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

UPD
попробовал включить эти флаги и все прекрасно откомпилировалось и слинковалось
разница правда небольшая:

mspgcc4: (GCC4.4):
text data bss dec hex filename
18424 6 1972 20402 4fb2 .\exe/epp.elf

mspgcc2011... (GCC 4.5):
text data bss dec hex filename
16684 6 1978 18668 48ec .\exe/epp.elf

mspgcc2011... (GCC4.5) c флагами -ffunction-sections -fdata-sections / -gc-sections:
text data bss dec hex filename
16682 6 1968 18656 48e0 .\exe/epp.elf


Сообщение отредактировал aliko - Aug 3 2011, 07:49

[AHTOXA]

Библиотечные будут поштучно. В принципе ничего страшного, если проект помещается в кристалл. Просто как-то это "неаккуратненько".

ЗЫ. Советую переключиться на четвёртую версию, раз уж она тоже заработала.

mspgcc2011... (GCC 4.5):
text data bss dec hex filename
16684 6 1978 18668 48ec .\exe/epp.elf

mspgcc2011... (GCC4.5) c флагами -ffunction-sections -fdata-sections / -gc-sections:
text data bss dec hex filename
16682 6 1968 18656 48e0 .\exe/epp.elf

2 байта? Это не то Ключ линкеру надо давать вот так:

Код

-Wl,--gc-sections

[aliko]

ЗЫ. Советую переключиться на четвёртую версию, раз уж она тоже заработала.

А я уже давно переключился, просто мейкфайл у меня с третьей версии а сам проект на четвертой... Точнее даже меняя ключ мейкфайла я могу скомпилировать проект и на 3й и на 4й версии ОС, чтобы если вдруг что не так пойдет была возможность преверить на др версии

2 байта? Это не то Ключ линкеру надо давать вот так:

Код

-Wl,--gc-sections

вот как выглядит строка флагов линкера у меня:

Код

ldflags        := -mmcu=$(cpu) -Wl,-Map=$(mapfile),--cref --gc-sections

что-то тут не так? все собирается вроде нормально...

[AHTOXA]

Код

ldflags        := -mmcu=$(cpu) -Wl,-Map=$(mapfile),--cref --gc-sections

Вместо пробела - запятая.

Код

ldflags        := -mmcu=$(cpu) -Wl,-Map=$(mapfile),--cref,--gc-sections

[aliko]

Вместо пробела - запятая.

Код

ldflags        := -mmcu=$(cpu) -Wl,-Map=$(mapfile),--cref,--gc-sections

Теперь перстало собираться

причем и на mspgcc4 (GCC4.4)

msp430-ld.exe: : No such file: Invalid argument
collect2: ld returned 1 exit status
make: *** [.\exe/epp.elf] Error 1

и на mspgcc2011.. (GCC4.5):

ld.exe : cannot find : Invalid argument
collect2: ld returned 1 exit status
make: *** [.\exe/epp.elf] Error 1

Сообщение отредактировал aliko - Aug 3 2011, 08:09

[AHTOXA]

Cобираться-то оно должно. Другое дело, что не работает
Напишите тогда

Код

-mmcu=$(cpu) -Wl,-Map=$(mapfile),--cref -Wl,--gc-sections

Или возьмите уже мейкфайл от 4й версии, просто поправьте линкер g++ на gcc, как я писал выше.

Нашёл в чём дело. В линкерном скрипте почему-то убраны KEEP от секций initX.
После исправления в файле MSPGCC\20110716\msp430\lib\ldscripts\msp430.x строчек

Код

    KEEP(*(.init))
    *(.init0)  /* Start here after reset.               */
    *(.init1)  /* User definable.                       */
    *(.init2)  /* Initialize stack.                     */
    *(.init3)  /* Initialize hardware, user definable.  */
    *(.init4)  /* Copy data to .data, clear bss.        */
    *(.init5)  /* User definable.                       */
    *(.init6)  /* C++ constructors.                     */
    *(.init7)  /* User definable.                       */
    *(.init8)  /* User definable.                       */
    *(.init9)  /* Call main().                          */

на

Код

    KEEP(*(.init))
    KEEP(*(.init0)) /* Start here after reset.               */
    KEEP(*(.init1)) /* User definable.                       */
    KEEP(*(.init2)) /* Initialize stack.                     */
    KEEP(*(.init3)) /* Initialize hardware, user definable.  */
    KEEP(*(.init4)) /* Copy data to .data, clear bss.        */
    KEEP(*(.init5)) /* User definable.                       */
    KEEP(*(.init6)) /* C++ constructors.                     */
    KEEP(*(.init7)) /* User definable.                       */
    KEEP(*(.init8)) /* User definable.                       */
    KEEP(*(.init9)) /* Call main().                          */

стало вроде всё нормально. (Проверить не смог, железку уже отдал

Ну ладно, вроде разобрались На днях закоммичу изменения.


ЗЫ. Вспомнил! Возьмите map-файл в кавычки:

Код

ldflags        := -mmcu=$(cpu) -Wl,-Map="$(mapfile)",--cref,--gc-sections

[aliko]

Нашёл в чём дело. В линкерном скрипте почему-то убраны KEEP от секций initX.
После исправления в файле MSPGCC\20110716\msp430\lib\ldscripts\msp430.x строчек

Исправил ВСЕ строчки initX согласно вашей рекомендации, однако это ни на байт не уменьшило размер программы...
Может надо было править только до main как в вашем примере?

[AHTOXA]

В моей рекомендации и так все строчки initX исправлены. Там дальше идут finiX - они в принципе не нужны
Вы с ключами-то разобрались? Если да, то попробуйте убрать KEEP() и откомпилируйте. Увидите сильное уменьшение размера программы (даже чересчур).

[aliko]

Вы с ключами-то разобрались? Если да, то попробуйте убрать KEEP() и откомпилируйте. Увидите сильное уменьшение размера программы (даже чересчур).

ключи мои вот:

Код

ldflags        := -mmcu=$(cpu) -Wl,-Map="$(mapfile)",--cref -W1,--gc-sections

еще пробовал вот так

Код

ldflags        := -mmcu=$(cpu) -Wl,-Map="$(mapfile)",--cref -W1,--gc-sections -Wl

Не совсем понял какие именно KEEP() убрать, убрал все что стоят перед каждым initX. На размер кода это влияния не оказало

UPD
Все получилось. у меня было --cref -W1 вместо --cref -Wl (L маленькая) %)

Сообщение отредактировал aliko - Aug 3 2011, 09:13

[AHTOXA]

Аминь

ЗЫ. Раз уж вы начали писать в рассылку mspgcc, может напишете про этот баг?

[aliko]

А каков смысл редактирования KEEP поясните пожалуйста? Размер кода уменьшается и без их добавления/убирания. Или это вы ошибку нашли в сборке mspgcc которую надо поправить?

[AHTOXA]

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

[aliko]

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

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


Написал в рассылку посвященную msp430.gcc
Ответил некий Peter Bigot по всей видимости один из разработчиков этого компилятора. Ниже вольный перевод:

Нет никаких причин использовать --gc-sections. Как вы выяснили он скорее всего уберет те вещи которые посчитает неиспользуемыми поскольку текущий скрипт линковщика говорит ему неправду.

Покрайней мере некоторые из этих "неправд" будут откорректированы в течение несольких часов когда я закончу перемещение все разработческих веток чтобы они базировались на GCC 4.6.0 и отправлю изменения которые я собрал у себя, тем не менее я не вижу никаких причин использовать этот флаг с mspgcc.

[AHTOXA]

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

Наверняка какой-нибудь скобочки не хватает (У меня есть разница в размере кода с KEEP и без. Надо будет найти железку и проверить живьём...)

Написал в рассылку посвященную msp430.gcc
Ответил некий Peter Bigot по всей видимости один из разработчиков этого компилятора.

Собственно, это нормальная реакция разработчика на рапорт вида "почему-то не работает" Надо же было написать, в чём причина! Тогда он скорее всего поправит.


---
Хм. Странно... Я до этого редактировал копию файла msp430.x, и явно указывал её в качестве линкерного скрипта (через LD_FLAGS += -T$(LD_SCRIPT) ). Теперь попробовал исправить оригинальный файл, и ничего не вышло. Пока не понимаю почему.


Короче, я так и не понял, в чём там дело. Похоже эти скрипты (20110716\msp430\lib\ldscripts\msp430.x*) лежат там чисто для справки. Даже их удаление ни на что не влияет.
Единственный рабочий вариант - сделать копию скрипта, (вставить руками в неё инклюды от соответствующего контроллера), сделать в ней исправления (KEEP) и указать её в качестве скрипта линкеру. При таких условиях -gc-sections работает нормально (проверил в железе).

[aliko]

Единственный рабочий вариант - сделать копию скрипта, (вставить руками в неё инклюды от соответствующего контроллера), сделать в ней исправления (KEEP) и указать её в качестве скрипта линкеру. При таких условиях -gc-sections работает нормально (проверил в железе).

Я тоже могу подтвердить. Мое железо тоже заработало!
Экономия в размере прошивки составила 22% что весьма не мало...

Сообщение отредактировал aliko - Aug 3 2011, 11:29

[AHTOXA]

Закоммитил исправления в pre-4.

[aliko]

Закоммитил исправления в pre-4.

Для mspgcc сегодня тоже были опубликованы патчи исправляющие ошибку с gc-sections.
Полезное получилось обсуждение

[Сергей Борщ]

Нашёл в чём дело. В линкерном скрипте почему-то убраны KEEP от секций initX.

А вот не все так просто. Там была хитрая задумка - в секции .init были ссылки на остальные секции .initX (если память не изменяет - в виде extern <метка>, другого способа я не нашел), поэтому она тянула за собой все секции инициализации. Если же пользователь переопределял точку входа по вектору сброса - не линковалась библиотечное содержимое секции .init и, следовательно, и содержимое остальных .initX тоже - весь стартап отключался разом. Видимо в новой версии binutils что-то изменили и этот механизм работать перестал. Так что я бы не стал утверждать, что это ошибка линкерных скриптов - там все это было сделано осознанно. Теперь для замены стартапа придется переопределать метки точек входа всех .initX секций.

[AHTOXA]

А вот не все так просто.

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

[aliko]

Проблемы с GCC кажется продолжаются.
При компиляции проекта последними версиями компилятора получается глючная прошивка. Под отладчиком все работает первый раз нормально, но после перезагрузки начинает сыпать мусор на ЖКИ устройства. В то же время при использовании старой версии компилятора (MSPGCC4 на базе GCC 4.4) подобного не наблюдается и программа работает стабильно. Беда в том что в старом mspgcc4 есть свои глюки в частности не работает printf.
Интересный момент: при открытии прошивки олимесковской программой она предупреждает : "Found data at address anavailable in the device" (Найдены данные по адресу недоступному на устройстве). При этом на прошивку полученную от компилятора mspgcc4 и которая работает нормально так не ругается. Я использую контроллер msp430f1611
Ниже я приведу дамп комманды readelf -e для бинарника который глючит. Может кто-то кто хорошо разбирается скажет есть ли в нем что-то не то из-за чего олимекс может так ругаться и программа глючить? К сожалению сам не особо силен в анализе этих данных...(

Код

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 ff 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            Standalone App
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Texas Instruments msp430 microcontroller
  Version:                           0x1
  Entry point address:               0x4000
  Start of program headers:          52 (bytes into file)
  Start of section headers:          288708 (bytes into file)
  Flags:                             0x10000000
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         6
  Size of section headers:           40 (bytes)
  Number of section headers:         36
  Section header string table index: 33

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al

  [ 0]                   NULL            00000000 000000 000000 00      0   0  0

  [ 1] .text             PROGBITS        00004000 000bae 007840 00  AX  0   0  2

  [ 2] .data             PROGBITS        00001100 0083ee 000014 00  WA  0   0  2

  [ 3] .bss              NOBITS          00001114 008402 000a99 00  WA  0   0  2

  [ 4] .noinit           NOBITS          00001bae 008402 0000c2 00  WA  0   0  2

  [ 5] .vectors          PROGBITS        0000ffe0 008402 000020 00  AX  0   0  1

  [ 6] .debug_aranges    PROGBITS        00000000 008424 00039c 00      0   0  4

  [ 7] .debug_pubnames   PROGBITS        00000000 0087c0 001fd8 00      0   0  1

  [ 8] .debug_info       PROGBITS        00000000 00a798 01fbc8 00      0   0  1

  [ 9] .debug_abbrev     PROGBITS        00000000 02a360 007bbf 00      0   0  1

  [10] .debug_line       PROGBITS        00000000 031f1f 005233 00      0   0  1

  [11] .debug_frame      PROGBITS        00000000 037152 001a1a 00      0   0  2

  [12] .debug_str        PROGBITS        00000000 038b6c 005270 01  MS  0   0  1

  [13] .debug_loc        PROGBITS        00000000 03dddc 006087 00      0   0  1

  [14] .debug_pubtypes   PROGBITS        00000000 043e63 00205f 00      0   0  1

  [15] .debug_ranges     PROGBITS        00000000 045ec2 000654 00      0   0  1

  [16] .rodata._ZL7xfCon PROGBITS        00001c70 0000f4 000058 00   A  0   0  2

  [17] .rodata._ZL10HART PROGBITS        00001cc8 00014c 00006a 00   A  0   0  2

  [18] .rodata.small_fon PROGBITS        00001d32 0001b6 00000e 00   A  0   0  2

  [19] .rodata._ZL16font PROGBITS        00001d40 0001c4 0003a8 00   A  0   0  1

  [20] .rodata._ZL24font PROGBITS        000020e8 00056c 000100 00   A  0   0  1

  [21] .rodata._ZL23font PROGBITS        000021e8 00066c 000138 00   A  0   0  2

  [22] .rodata._ZL23font PROGBITS        00002320 0007a4 000138 00   A  0   0  2

  [23] .rodata.big_font  PROGBITS        00002458 0008dc 00000e 00   A  0   0  2

  [24] .rodata._ZL19font PROGBITS        00002466 0008ea 000128 00   A  0   0  1

  [25] .rodata._ZL22font PROGBITS        0000258e 000a12 000100 00   A  0   0  1

  [26] .rodata._ZL20font PROGBITS        0000268e 000b12 00000d 00   A  0   0  1

  [27] .rodata._ZL21font PROGBITS        0000269c 000b20 00001a 00   A  0   0  2

  [28] .rodata._ZL21font PROGBITS        000026b6 000b3a 00001a 00   A  0   0  2

  [29] .rodata._ZL12adc_ PROGBITS        000026d0 000b54 000005 00   A  0   0  1

  [30] .rodata._ZL11cons PROGBITS        000026d5 000b59 000040 00   A  0   0  1

  [31] .rodata._ZL8bits_ PROGBITS        00002715 000b99 000010 00   A  0   0  1

  [32] .rodata._ZL8bits_ PROGBITS        00002725 000ba9 000005 00   A  0   0  1

  [33] .shstrtab         STRTAB          00000000 046516 0002ab 00      0   0  1

  [34] .symtab           SYMTAB          00000000 046d64 0026e0 10     35 147  4

  [35] .strtab           STRTAB          00000000 049444 002ae1 00      0   0  1

Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00001b7c 0x00001b7c 0x00b1f 0x00b1f R   0x1
  LOAD           0x000b20 0x0000269c 0x0000269c 0x0008e 0x0008e R   0x1
  LOAD           0x000bae 0x00004000 0x00004000 0x07840 0x07840 R E 0x1
  LOAD           0x0083ee 0x00001100 0x0000b840 0x00014 0x00aad RW  0x1
  LOAD           0x008402 0x00001bae 0x0000b854 0x00000 0x000c2 RW  0x1
  LOAD           0x008402 0x0000ffe0 0x0000ffe0 0x00020 0x00020 R E 0x1

Section to Segment mapping:
  Segment Sections...
   00     .noinit .rodata._ZL7xfConfD .rodata._ZL10HART_confD .rodata.small_font
.rodata._ZL16font_small_table .rodata._ZL24font_small_mapping_table .rodata._ZL
23font_small_offset_table .rodata._ZL23font_small_detail_table .rodata.big_font
.rodata._ZL19font_big_char_table .rodata._ZL22font_big_mapping_table .rodata._ZL
20font_big_width_table
   01     .rodata._ZL21font_big_offset_table .rodata._ZL21font_big_detail_table
.rodata._ZL12adc_channels .rodata._ZL11const_types .rodata._ZL8bits_cnt .rodata.
_ZL8bits_msk
   02     .text
   03     .data .bss
   04     .noinit
   05     .vectors

Сообщение отредактировал aliko - Aug 29 2011, 10:57

[aliko]

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

[aliko]

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

[Сергей Борщ]

лучше пока воздержаться от его использования...

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