[Arlleex 187]

5 часов назад, haker_fox сказал:

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

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

Цитата

Weak references

Weak symbol references can be used in a similar way to weak symbol definitions. They can act as placeholders until the actual definition becomes available. This placeholder allows you the option to begin testing a particular part of the application, for example, at an earlier stage in the project, without having to wait for a new module that contains the definition to become available.

// foo.c
void bar(void) __attribute__ ((weak)); // weak function prototype declaration for bar()

void foo(void) // global function definition for foo()
{
  bar(); // global function reference bar() with weak binding
}

This example contains a weak symbol reference to the function bar(). An unresolved weak function call is replaced with either:

• A no-operation instruction, NOP.

• A branch with link instruction, BL, to the following instruction. That is, the function call does not happen.

When the module that contains the definition for bar() is finally ready, it can be linked in instead.

[Arlleex 187]

Следующий баг.

Keil uVision 5.36, тулчейн V6.16.

Есть такой скрипт компоновщика

LOAD1 0x08000000 8192 {
  ROOT 0x08000000 8192 {
    *.o (RESET, +first)
    *(InRoot$$Sections)
    .any (+ro)
  }
  
  RAM1 0x20000000 UNINIT 16 {
    *(.bss.bootInfo)
  }
  
  RAM2 0x20000010 20464 {
    .any (+rw, +zi)
  }
}

В проекте есть два различных .c-файла: file1.c и file2.c.

В file1.c в глобальной области файла

static struct {
  char key[8];
  
  u32  entryFlags;
} volatile BootInfo __attribute__((section(".bss.bootInfo")));

В file2.c тоже в глобальной области файла

static struct {
  u32 isConnected       :  1,
      isWBufFillingMode :  1,
                        : 30;
  
  u32 wBufOffset;
  u8  wBuf[WBUF_SIZE];
  
  u32 memoryOffset;
} BootInfo;

При любом уровне оптимизации без LTO получаю ошибку компоновки

Цитата

Error: L6220E: Execution region RAM1 size (56 bytes) exceeds limit (16 bytes). Region contains 0 bytes of padding and 0 bytes of veneers (total 0 bytes of linker generated content).

Error: L6221E: Execution region RAM1 with Execution range [0x20000000,0x20000038) overlaps with Execution region RAM2 with Execution range [0x20000010,0x20001050).

Именование секции .bss.bootInfo в соответствиями с особенностями определения неинициализированных переменных.

С галкой LTO-оптимизации компиляция и линковка проходит успешно, в map-файле все ок.

Т.е. компилятор никак не "усложняет" имена переменных, чтобы два разных файла экспортировали разные символы пусть даже одинаково названных статических переменных (при явном размещении в секции .bss.bootInfo).

[x893 60]

11 hours ago, Arlleex said:

Следующий баг.

Keil uVision 5.36, тулчейн V6.16.

Есть такой скрипт компоновщика

LOAD1 0x08000000 8192 {
  ROOT 0x08000000 8192 {
    *.o (RESET, +first)
    *(InRoot$$Sections)
    .any (+ro)
  }
  
  RAM1 0x20000000 UNINIT 16 {
    *(.bss.bootInfo)
  }
  
  RAM2 0x20000010 20464 {
    .any (+rw, +zi)
  }
}

В проекте есть два различных .c-файла: file1.c и file2.c.

В file1.c в глобальной области файла

static struct {
  char key[8];
  
  u32  entryFlags;
} volatile BootInfo __attribute__((section(".bss.bootInfo")));

В file2.c тоже в глобальной области файла

static struct {
  u32 isConnected       :  1,
      isWBufFillingMode :  1,
                        : 30;
  
  u32 wBufOffset;
  u8  wBuf[WBUF_SIZE];
  
  u32 memoryOffset;
} BootInfo;

При любом уровне оптимизации без LTO получаю ошибку компоновки

Именование секции .bss.bootInfo в соответствиями с особенностями определения неинициализированных переменных.

С галкой LTO-оптимизации компиляция и линковка проходит успешно, в map-файле все ок.

Т.е. компилятор никак не "усложняет" имена переменных, чтобы два разных файла экспортировали разные символы пусть даже одинаково названных статических переменных (при явном размещении в секции .bss.bootInfo).

Так напишите в arm и пусть исправляют.

[Arlleex 187]

3 часа назад, x893 сказал:

Так напишите в arm и пусть исправляют.

Напишу, посмотрим, что выйдет.

[jcxz 241]

13 минут назад, Arlleex сказал:

Напишу, посмотрим, что выйдет.

Неужто не попросят ваш номер лицензии?   Или вы купили Keil?  

[Arlleex 187]

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

Неужто не попросят ваш номер лицензии?   Или вы купили Keil?  

А я на их триальной 32кБ версии продемонстрирую😉

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

[Obam 38]

...жду завершения регистрации.
Ага, они щас из России ждут-не дождутся баг-репортов. Так, что даже доку на сайте без vpn не глянуть\качнуть.

[Arlleex 187]

9 часов назад, Obam сказал:

...жду завершения регистрации.
Ага, они щас из России ждут-не дождутся баг-репортов. Так, что даже доку на сайте без vpn не глянуть\качнуть.

Вас это когда-то останавливало?

[jcxz 241]

23 часа назад, Arlleex сказал:

А я на их триальной 32кБ версии продемонстрирую😉

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

В своё время, когда общался с IAR-овцами по аналогичным вопросам (находил баги в IAR), любое обращение начиналось с вопроса о номере нашей лицензии (она у нас есть, платная). Т.е.  пишешь им: "Обнаружил такой-то баг"; с полным описанием и примером в котором он воспроизводится - всё честь по чести, а в ответ сразу: "Назовите номер вашей лицензии". И только после этого начиналось общение по существу. Я думаю, что на приёме обращений там сидит кто-то (девочка?), не шарящий в технических деталях, чья задача - отсеять бОльшую часть мусорных обращений. Ведь думаю - ~99% (если не больше) таких обращений к ним - от дилетантов, которые не отличают баг компилятора от своего.

А проще всего и быстрее - отсеять по формальному признаку. Типа номера лицензии. Сами поставьте себя на место тех.поддержки такой конторы. У которой сотни тысяч пользователей или больше (подавляющее большинство из которых - нелегальные). И подумайте - как вы будете реагировать, когда в очередной 100500-й раз получите сообщение "ваш компилятор глючит!" от очередного чайника. А раз смогли заплатить за платную лицензию - значит вероятность того, что не чайник - мноог выше.

Сугубо - ИМХО!  

 

PS: Но конечно - попробуйте обратиться. И напишите - какой будет результат. Keil-ом я не пользуюсь, но всё равно интересно.

[Arlleex 187]

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

А проще всего и быстрее - отсеять по формальному признаку. Типа номера лицензии.

Это да... но у кейла официально некоммерческая лицензия (типа, скачал - поставил - компилируй) бесплатная до размера образа прошивки 32кБ.
 

Цитата

PS: Но конечно - попробуйте обратиться. И напишите - какой будет результат. Keil-ом я не пользуюсь, но всё равно интересно.

Написал обращение в службу поддержки с описанием бага, архив с проектом приложил. Ну и на общедоступный форум по кейлу тоже закинул вопрос, на всякий.

[jcxz 241]

В 26.07.2024 в 21:22, Arlleex сказал:

Т.е. компилятор никак не "усложняет" имена переменных, чтобы два разных файла экспортировали разные символы пусть даже одинаково названных статических переменных (при явном размещении в секции .bss.bootInfo).

А разве он должен это делать? Ведь у вас .c-файлы, а не .cpp.

Мне казалось, что манглинг имён вроде только есть начиная с c++.

[Arlleex 187]

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

А разве он должен это делать? Ведь у вас .c-файлы, а не .cpp.

Мне казалось, что манглинг имён вроде только в c++ есть.

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

[jcxz 241]

29 минут назад, Arlleex сказал:

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

А разве они должны быть? Искажения имён.

Имхо - в именах объектов в си как раз не должно быть отличий. Могут быть в атрибутах. За счёт которых правильно выполняется статическое связывание при компоновке. Но как эти атрибуты влияют на размещение в регионы памяти - вопрос.

Хотя согласен, что должен раскидать в разные регионы. Раз целевая секция у них разная.

Попробовал ваш пример на IAR 7.80.4.

file1.c:

__root static struct {
  char key[8];
  u32  entryFlags;
} volatile BootInfo __attribute__((section(".bss.bootInfo")));

file2.c:

enum {WBUF_SIZE = 44};
__root static struct {  
  u32 isConnected       :  1,
      isWBufFillingMode :  1,
                        : 30;
  u32 wBufOffset;
  u8  wBuf[WBUF_SIZE];
  u32 memoryOffset;
} BootInfo;

.icf:

define region RAM_regionA   = mem:[from 0x20000000 size 0x00010];
define region RAM_regionB   = mem:[from 0x20000010 size 0x0FFF0];
...
place in RAM_regionB { rw };
place in RAM_regionA { section .bss.bootInfo };

.map:

...
BootInfo                0x20000000     0xc  Data  Lc  file1.o [1]  
BootInfo                0x20003c20    0x38  Data  Lc  file2.o [1]  
...

Как видно - всё ок. Без ошибок и варнингов. си, C99.

Хотя разницы в именах нет никакой.

[Arlleex 187]

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

А разве они должны быть? Искажения имён.

Вот пример map при включенном LTO - т.е. когда собирается все правильно

BootInfo                                 0x20000000   Data          12  lto-llvm-efc174.o(.bss.bootInfo)
[Anonymous Symbol]                       0x20000000   Section        0  lto-llvm-efc174.o(.bss.bootInfo)
BootInfo.36                              0x20000034   Data          44  lto-llvm-efc174.o(.bss.BootInfo.36)
[Anonymous Symbol]                       0x20000034   Section        0  lto-llvm-efc174.o(.bss.BootInfo.36)

Вот этот хвост .36 - и есть искажение.

Ровно такой же результат будет, если я уберу из скрипта компоновщика определение секции .bss.bootInfo, а из соответствующего определения структуры уберу атрибут размещения в этой секции. Проект соберется, и map будет такой же, как четыре строчки выше (за исключением адресов). Если добавить в какой-нибудь еще другой исходный файл еще одну структуру BootInfo (тоже статическую) - то для нее будет сгенерирован другой хвост. Например (проэкспериментировал)

BootInfo                                 0x20000034   Data          16  lto-llvm-5f0b2f.o(.bss.BootInfo)
__tagsym$$used.0                         0x20000034   Number         0  lto-llvm-5f0b2f.o(.bss.BootInfo)
[Anonymous Symbol]                       0x20000034   Section        0  lto-llvm-5f0b2f.o(.bss.BootInfo)
BootInfo.12                              0x20000044   Data          12  lto-llvm-5f0b2f.o(.bss.BootInfo.12)
[Anonymous Symbol]                       0x20000044   Section        0  lto-llvm-5f0b2f.o(.bss.BootInfo.12)
BootInfo.38                              0x20000050   Data          44  lto-llvm-5f0b2f.o(.bss.BootInfo.38)
[Anonymous Symbol]                       0x20000050   Section        0  lto-llvm-5f0b2f.o(.bss.BootInfo.38)

P.S. А. Да, забыл снять галку LTO. Когда ее снимаю, map

BootInfo                                 0x20000034   Data          16  flash.o(.bss.BootInfo)
__tagsym$$used.0                         0x20000034   Number         0  flash.o(.bss.BootInfo)
[Anonymous Symbol]                       0x20000034   Section        0  flash.o(.bss.BootInfo)
BootInfo                                 0x20000044   Data          12  boot.o(.bss.BootInfo)
[Anonymous Symbol]                       0x20000044   Section        0  boot.o(.bss.BootInfo)
BootInfo                                 0x20000050   Data          44  can_bootloader.o(.bss.BootInfo)
[Anonymous Symbol]                       0x20000050   Section        0  can_bootloader.o(.bss.BootInfo)

Как видно, "видимых" искажений нет. Но, думаю, он у себя внутри под капотом искажает чутка, добавляя имя объектного файла или как-то еще. В общем, суть остается та же - при "ручном" размещении в секциях линкер чутка ломается.

[jcxz 241]

17 минут назад, Arlleex сказал:

Вот пример map при включенном LTO - т.е. когда собирается все правильно

BootInfo                                 0x20000000   Data          12  lto-llvm-efc174.o(.bss.bootInfo)
[Anonymous Symbol]                       0x20000000   Section        0  lto-llvm-efc174.o(.bss.bootInfo)
BootInfo.36                              0x20000034   Data          44  lto-llvm-efc174.o(.bss.BootInfo.36)
[Anonymous Symbol]                       0x20000034   Section        0  lto-llvm-efc174.o(.bss.BootInfo.36)

Странно... А почему так? У вас же для второй (большой) структуры нету переопределения имени секции (в исходнике). Тогда почему компилятор её в ".bss.BootInfo" пихает? А не в дефолтную ".bss".

Или в Кейл у вас стоит какой-то ключ типа: "для каждого объекта задавать свою именованную секцию"?

Может тогда проблема в том, что имена секций ".bss.bootInfo" vs ".bss.BootInfo" - отличаются только регистром буков? И линковщик, не различая регистра, пытается компоновать их обе в регион RAM1.

А если скажем: для первой структуры задать имя секции, отличающееся от ".bss.BootInfo" не только регистром буков?