Все о ARM GCC4.3, Linker, ASM, C/C++, Windows/Linux. Опции

[Vitaliy_ARM]

Все больше прощаюсь с IAR.

Разбираюсь с компановщиком. Документация на него не впечатлила . Есть ли у кого готовый пример скрипта размещения констант по указанному адресу во Flash LPC2xxx или другого арма?

[zltigo]

Все больше прощаюсь с IAR.

Много полезне вместо демонстративного прощания с IAR тихо и навсегда попрощаться с дурной привычкой "размещения констант по указанному адресу во Flash". Ну а инструментарий у V5 IAR суть есть GNU-тый....

[Vitaliy_ARM]

Много полезне вместо демонстративного прощания с IAR тихо и навсегда попрощаться с дурной привычкой "размещения констант по указанному адресу во Flash". Ну а инструментарий у V5 IAR суть есть GNU-тый....

В моей задаче это просто не возможно. Бутлодер + Программа имеют две константы - мак адрес и ай пи адрес, строго расположенные в указанных местах. И то и то должно иметь доступ к этим ячейкам. Прощание с "дурной привычкой" не позволить сделать программу и бутлодер независымыми .

Сообщение отредактировал Vitaliy_ARM - Dec 10 2008, 13:44

[zltigo]

Прощание с "дурной привычкой" не позволить сделать программу и бутлодер независымыми .

Примерно в аналогичных случаях в фиксированном месте boot (сразу после векторов) размещаю УКАЗАТЕЛЬ на находящийся в произвольном месте блок общих данных. Boot, естественно, линкуется в конкретное место, но это единственная по любому необходимая привязка к адресам - сущности более не плодятся.

[Vitaliy_ARM]

Примерно в аналогичных случаях в фиксированном месте boot (сразу после векторов) размещаю УКАЗАТЕЛЬ на находящийся в произвольном месте блок общих данных. Boot, естественно, линкуется в конкретное место, но это единственная по любому необходимая привязка к адресам - сущности более не плодятся.

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

[zltigo]

Ага, а как тогда....

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

[Vitaliy_ARM]

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

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

Как-то так. Выделяете регион памяти(CONFIG), потом складываете в него нужные сегменты (*.config)[code]/* memory layout */

Вроде бы прояснилось.

[Vitaliy_ARM]

Генерирование отладочной информации в коде процессора - подскажите, что это такое и с чем его едят?
Где можно почитать об этом (строчки в скрипте компоновщика)?

Код

/* Stabs debugging sections.  */
  .stab          0 : { *(.stab) }
  .stabstr       0 : { *(.stabstr) }
  .stab.excl     0 : { *(.stab.excl) }
  .stab.exclstr  0 : { *(.stab.exclstr) }
  .stab.index    0 : { *(.stab.index) }
  .stab.indexstr 0 : { *(.stab.indexstr) }
  .comment       0 : { *(.comment) }
  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the beginning
     of the section so we begin them at 0.  */
  /* DWARF 1 */
  .debug           0 : { *(.debug) }
  .line            0 : { *(.line) }
  /* GNU DWARF 1 extensions */
  .debug_srcinfo   0 : { *(.debug_srcinfo) }
  .debug_sfnames   0 : { *(.debug_sfnames) }
  /* DWARF 1.1 and DWARF 2 */
  .debug_aranges   0 : { *(.debug_aranges) }
  .debug_pubnames  0 : { *(.debug_pubnames) }
  /* DWARF 2 */
  .debug_info      0 : { *(.debug_info .gnu.linkonce.wi.*) }
  .debug_abbrev    0 : { *(.debug_abbrev) }
  .debug_line      0 : { *(.debug_line) }
  .debug_frame     0 : { *(.debug_frame) }
  .debug_str       0 : { *(.debug_str) }
  .debug_loc       0 : { *(.debug_loc) }
  .debug_macinfo   0 : { *(.debug_macinfo) }
  /* SGI/MIPS DWARF 2 extensions */
  .debug_weaknames 0 : { *(.debug_weaknames) }
  .debug_funcnames 0 : { *(.debug_funcnames) }
  .debug_typenames 0 : { *(.debug_typenames) }
  .debug_varnames  0 : { *(.debug_varnames) }

Сообщение отредактировал Vitaliy_ARM - Jan 19 2009, 11:27

[amw]

Генерирование отладочной информации в коде процессора - подскажите, что это такое и с чем его едят?
Где можно почитать об этом (строчки в скрипте компоновщика)?

Код

/* Stabs debugging sections.  */
  .stab          0 : { *(.stab) }
  .stabstr       0 : { *(.stabstr) }
  .stab.excl     0 : { *(.stab.excl) }
  .stab.exclstr  0 : { *(.stab.exclstr) }
  .stab.index    0 : { *(.stab.index) }
  .stab.indexstr 0 : { *(.stab.indexstr) }
  .comment       0 : { *(.comment) }
  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the beginning
     of the section so we begin them at 0.  */
  /* DWARF 1 */
  .debug           0 : { *(.debug) }
  .line            0 : { *(.line) }
  /* GNU DWARF 1 extensions */
  .debug_srcinfo   0 : { *(.debug_srcinfo) }
  .debug_sfnames   0 : { *(.debug_sfnames) }
  /* DWARF 1.1 and DWARF 2 */
  .debug_aranges   0 : { *(.debug_aranges) }
  .debug_pubnames  0 : { *(.debug_pubnames) }
  /* DWARF 2 */
  .debug_info      0 : { *(.debug_info .gnu.linkonce.wi.*) }
  .debug_abbrev    0 : { *(.debug_abbrev) }
  .debug_line      0 : { *(.debug_line) }
  .debug_frame     0 : { *(.debug_frame) }
  .debug_str       0 : { *(.debug_str) }
  .debug_loc       0 : { *(.debug_loc) }
  .debug_macinfo   0 : { *(.debug_macinfo) }
  /* SGI/MIPS DWARF 2 extensions */
  .debug_weaknames 0 : { *(.debug_weaknames) }
  .debug_funcnames 0 : { *(.debug_funcnames) }
  .debug_typenames 0 : { *(.debug_typenames) }
  .debug_varnames  0 : { *(.debug_varnames) }

Это отрывок скрипта линкера. Он указывает, куда линкер будет ложить отладочную информацию в исполняемый файл.
Генерируется она компилятором, при использовании ключа -g с опциями. Например (варианты)

Код

gcc -g main .o main.c
gcc -g3 main .o main.c
gcc -ggdb main .o main.c
gcc -gdwarf-2 main .o main.c

Линкуется потом обычным способом (линкеру не имеет особых флагов для отладочной информации).
После этого можно спокойно отлаживать программу с помощью gdb.

[Vitaliy_ARM]

Это отрывок скрипта линкера. Он указывает, куда линкер будет ложить отладочную информацию в исполняемый файл.
Генерируется она компилятором, при использовании ключа -g с опциями. Например (варианты)

Код

gcc -g main .o main.c
gcc -g3 main .o main.c
gcc -ggdb main .o main.c
gcc -gdwarf-2 main .o main.c

Линкуется потом обычным способом (линкеру не имеет особых флагов для отладочной информации).
После этого можно спокойно отлаживать программу с помощью gdb.

Да, уже разобрался. Есть еще некоторые непонятности.
Как я понимаю OpenOCD уже научился поддерживать J-Link и еще кучу всяких Jtag. Но для этого надо ли его пересобрать? Кто-нибудь пользуется связкой Eclipse+GCC+OpenOCD+J-Link?