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

Область видимость констант линкера

32 минуты назад, AlexRayne сказал:

А удавалось ли Вам положить в самый конец прошивы секцию?

В смысле "удавалось"? У меня естественно как указано в .icf, так и лежит в памяти.

32 минуты назад, AlexRayne сказал:

У меня ИАР после 

last section

еще докладывает  секцию  с "Initializer bytes    const" - она делается после сборки всех секций, и не удается мне положить чтото за ней

Что-то у вас не так видимо в .icf или ещё где-то.

 

PS: Часть .map из текущего проекта:

  Section             Kind        Address     Size  Object
  -------             ----        -------     ----  ------
"P1":                                      0x16dc0
  IMAGE_HEAD                   0x08000000    0x228  <Block>
    .intvec                    0x08000000     0x20  <Block>
      .intvec         const    0x08000000     0x20  misca.o [1]
    .checksum         const    0x08000020      0x4  Place holder __checksum
    .codehead         const    0x08000024      0x8  misca.o [1]
    .intvecTail       const    0x0800002c    0x1d0  misca.o [1]
    .codeSignature    const    0x080001fc     0x2c  adc.o [1]
  .tPow10             const    0x08000228     0xa0  adc.o [1]
  .const              const    0x080002c8   0x1808  adc.o [1]
  
...

  .text               ro code  0x08016d26      0x6  abort.o [3]
  .iar.init_table     const    0x08016d2c     0x30  - Linker created -
  .codeheadExt0       const    0x08016d5c      0x0  misca.o [1]
  .rodata             const    0x08016d5c      0x0  zero_init3.o [5]
  .rodata             const    0x08016d5c      0x0  packbits_init.o [5]
  Initializer bytes   const    0x08016d5c     0x58  <for P4-1>
  .codetail                    0x08016db4      0xc  <Block>
    .codetail         const    0x08016db4      0xc  misca.o [1]
                             - 0x08016dc0  0x16dc0

"P2":                                         0xe0
  .textrw             uninit   0x1000fc00     0xe0  adc.o [1]
                             - 0x1000fce0     0xe0

...

Как видно - .codetail лежит в самом конце флеша (дальше идёт уже регион ОЗУ).

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


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

1 час назад, jcxz сказал:

то-то у вас не так видимо в .icf или ещё где-то.

вот мой icf

...
define block CHECKSUM  { ro section .checksum };

initialize by copy { readwrite };
do not initialize  { section .noinit };
keep { section .checksum* };

place at address mem:__ICFEDIT_intvec_start__ { readonly section .intvec };
place at address mem:__Reset_Handler_text_start__ { readonly section .Reset_Handler_text };
place in ROM_region   { readonly };
place in RAM_region   { readwrite,
                        block CSTACK, block HEAP };
place in ROM_region    { last block CHECKSUM };

а линкер отчитывается так:
 

*******************************************************************************
*** PLACEMENT SUMMARY
***

"A0":  place at address 0x0 { ro section .intvec };
"A1":  place at address 0xc0 { ro section .Reset_Handler_text };
"P1":  place in [from 0x0 to 0x7'ffff] { ro };
define block CSTACK with size = 1K, alignment = 8 { };
define block HEAP with size = 1K, alignment = 8 { };
"P2":  place in [from 0x2000'0000 to 0x2000'ffff] {
          rw, block CSTACK, block HEAP };
define block CHECKSUM { ro section .checksum };
"P3":  place in [from 0x0 to 0x7'ffff] { last block CHECKSUM };
initialize by copy { rw };
keep { section .checksum* };
"P1", part 1 of 2:                              
	.text	...
	.rodata	...

"P3":                                             0x2
  CHECKSUM                         0x2'e884       0x2  <Block>
    .checksum          zero        0x2'e884       0x2  crc_fw.o [9]
                                 - 0x2'e886       0x2

"P1", part 2 of 2:                              0x1b8
  Initializer bytes    const       0x2'e886     0x1b8  <for P2-1>
                                 - 0x2'ea3e     0x1b8
    
"P2", part 1 of 3:                             0x2c21
  P2-1                          0x2000'0000    0x2c21  <Init block>
    .data              inited   0x2000'0000      0xc8  cosem_app_calendar.o [11]
    ...

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

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


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

1 час назад, AlexRayne сказал:

вот мой icf

А зачем вы задали два отдельных place-правила для одного региона?:

place in ROM_region   { readonly };
place in ROM_region    { last block CHECKSUM };

Может в этом проблема. Попробуйте объединить.

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


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

32 минуты назад, jcxz сказал:

Может в этом проблема. Попробуйте объединить.

Спасибо! сработало

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


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

В 30.08.2024 в 16:19, jcxz сказал:

Может в этом проблема. Попробуйте объединить.

только оно положило в конец секции c ro, а мне надо отдельной секцией блок CHECKSUM, поэтому я его отдельным правилом и добавлял

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


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

В 01.09.2024 в 00:25, AlexRayne сказал:

только оно положило в конец секции c ro, а мне надо отдельной секцией блок CHECKSUM, поэтому я его отдельным правилом и добавлял

Вы пишете что-то странное... По вашему же .icf видно, что CRC у вас и так идёт - отдельной секцией. Вы же сами ссылаетесь на имя этой секции: ".checksum". Значит видимо и в .map у вас CRC - отдельной секцией ".checksum" (да и как может быть иначе? - IAR у всех один).

Также не понятно - зачем вы создаёте блок CHECKSUM? Какой в этом смысл? Ведь внутри его всего одна секция.

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


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

В 02.09.2024 в 13:04, jcxz сказал:

Вы пишете что-то странное... По вашему же .icf видно, что CRC у вас и так идёт - отдельной секцией. Вы же сами ссылаетесь на имя этой секции: ".checksum". Значит видимо и в .map у вас CRC - отдельной секцией ".checksum" (да и как может быть иначе? - IAR у всех один).

Также не понятно - зачем вы создаёте блок CHECKSUM? Какой в этом смысл? Ведь внутри его всего одна секция.

это секция объектного файла. А в итоговом elf все секции объектов кидаются в секции elf - для rw - своя, для ro - своя. и вот для cheksum - получается своя. Их именование перпендикулярно тому что мы привыкли видеть в линкере - он както по своему именует:
 

"A0":  place at address 0x0 { ro section .intvec };
"A1":  place at address 0xc0 { ro section .Reset_Handler_text };
"P1":  place in [from 0x0 to 0x7'ffff] { ro };
define block CSTACK with size = 1K, alignment = 8 { };
define block HEAP with size = 1K, alignment = 8 { };
"P2":  place in [from 0x2000'0000 to 0x2000'ffff] {
          rw, block CSTACK, block HEAP };
define block CHECKSUM { ro section .checksum };
"P3":  place in [from 0x0 to 0x7'ffff] { last block CHECKSUM };

Вот эти An, Pn - это и есть секции в итоговом elf

Классические gnu тулы могут конешн видеть символы, но исходных секций объектов - их просто нет, а есть секции итогового образа. 
Еслиб тулы позволяли заменять содержимое символов - небыло б проблем. Но objcopy умеет менять только содержимое целой секции, поэтому checksum мне надо отдельно

 

 

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

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


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

12 минут назад, AlexRayne сказал:

Еслиб тулы позволяли заменять содержимое символов - небыло б проблем. Но objcopy умеет менять только содержимое целой секции, поэтому checksum мне надо отдельно

Пускай так. Но как тут поможет выделение .checksum в отдельный block? Ведь block-и обрабатываются вроде как точно так же, как входные sections.

 

PS: Чтобы изменить правила объединения входных секций, можно попробовать задать атрибуты нужной секции явно - посредством директивы SECTION ассемблера.

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


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

Только что, jcxz сказал:

Пускай так. Но как тут поможет выделение .checksum в отдельный block?

я ж показал листинг
 

"P3":                                             0x2
  CHECKSUM                         0x2'e884       0x2  <Block>
    .checksum          zero        0x2'e884       0x2  crc_fw.o [9]
                                 - 0x2'e886       0x2

отдельным правилом линкер заводит отдельную секцию P3 для checksum. эту секцию я потом могу менять

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


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

4 минуты назад, AlexRayne сказал:

я ж показал листинг
 

"P3":                                             0x2
  CHECKSUM                         0x2'e884       0x2  <Block>
    .checksum          zero        0x2'e884       0x2  crc_fw.o [9]
                                 - 0x2'e886       0x2

отдельным правилом линкер заводит отдельную секцию P3 для checksum. эту секцию я потом могу менять

Я вас не про отдельное place-правило спрашивал. А про выделение секции .checksum в блок CHECKSUM. Зачем?

 

PS: И какой смысл говорить о двух правилах для одного региона памяти, если уже ясно что так правила работают криво? (т.е. - вообще не работают так)

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


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

3 минуты назад, jcxz сказал:

PS: И какой смысл говорить о двух правилах для одного региона памяти, если уже ясно что так правила работают криво? (т.е. - вообще не работают так)

я ж написал - мне нужна отдельная секция.

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

Я вас не про отдельное place-правило спрашивал. А про выделение секции .checksum в блок CHECKSUM. Зачем?

если не положить секцию в блок - линкер её кладет в первое подходящее правило, а на втором выдает ошибку множественного подходящего патерна.

как исключить секцию из правила не ведаю.

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


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

18 минут назад, AlexRayne сказал:

я ж написал - мне нужна отдельная секция.

Сразу бы сказали, что вам нужна отдельная выходная секция для checksum. Т.е. - ELF-секция. В терминологии компоновщика IAR секции бывают входные(input) и выходные(output). Первые - входные данные для компоновщика, вторые - его результат работы. Вот второе - как раз и есть ваши ELF-секции. 

18 минут назад, AlexRayne сказал:

как исключить секцию из правила не ведаю.

place-правила - это вообще имхо не о том. place-правила задают компоновку секций в регионы памяти. Они к выходным секциям никак не относятся. Думаю - в пределы одного региона вполне могут быть скомпонованы выходные секции разных типов. Посредством единого place-правила. А чтобы разные входные секции не объединялись в одну выходную, у них должны быть разные атрибуты. Для этого можно попробовать изменить атрибуты нужной секции как я писал выше.

Насколько я знаю: в единые выходные секции объединяются только входные секции с одинаковыми (или совместимыми) атрибутами.

46 минут назад, AlexRayne сказал:

в секции elf - для rw - своя, для ro - своя.

ro и rw - это не выходные секции. Это как раз - атрибуты входных секций. Кроме них могут быть и другие атрибуты.

А запись 'ro' внутри place-правила, требует применять это правило ко всем секциям, имеющим атрибут 'ro'. Можно убрать 'ro' из place-правила и явно перечислить нужные секции (по именам) которые нужно компоновать в данный регион.

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


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

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

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

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

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

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

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

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

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