Size: a a a

2021 March 13

MD

Mikhail Demchenko in pro.cxx
Mikhail Voronov
а никто случайно не пробовал генерировать кастомные секции для васма? Я пытаюсь сделать как-то так

const unsigned char __FCE_SDK_VERSION[6] __attribute__((section(".custom_section.__fce_sdk_version"))) = "0.5.0";

но даже с --no-gc-sections в результирующем васм бинарнике её не появляется
Тебе необходимо написать свой линкер скрипт, так как линкер не в курсе куда это твои секции из obj файлов девать при линковке, он их и выбрасывает просто. Посмотри objdump на бинарник obj файла, там секции должны быть
источник

MD

Mikhail Demchenko in pro.cxx
Mikhail Voronov
а где можно найти доку по линкер скриптам для lld?
На сайте gnu утилит как обычно, или на gcc.org где-то должно быть. Вообще также может есть что-то в Documentation разделе сорсов линухов
источник

DF

Dollar Føølish in pro.cxx
Mikhail Voronov
а никто случайно не пробовал генерировать кастомные секции для васма? Я пытаюсь сделать как-то так

const unsigned char __FCE_SDK_VERSION[6] __attribute__((section(".custom_section.__fce_sdk_version"))) = "0.5.0";

но даже с --no-gc-sections в результирующем васм бинарнике её не появляется
Васм вообще какие секции поддерживает ? Произвольные ?
источник

DF

Dollar Føølish in pro.cxx
Mikhail Demchenko
На сайте gnu утилит как обычно, или на gcc.org где-то должно быть. Вообще также может есть что-то в Documentation разделе сорсов линухов
Ему же ллд а не лд
источник

DF

Dollar Føølish in pro.cxx
Mikhail Voronov
а где можно найти доку по линкер скриптам для lld?
Скрипты от обычного лд не подходят?
источник

MV

Mikhail Voronov in pro.cxx
Dollar Føølish
Васм вообще какие секции поддерживает ? Произвольные ?
Кастомные произвольные да, там любая бинарная строка может храниться
источник

MV

Mikhail Voronov in pro.cxx
Dollar Føølish
Скрипты от обычного лд не подходят?
Нет еще, сегодня попробую
источник

MV

Mikhail Voronov in pro.cxx
Вообще странно, что флаг --no-gc-sections линкера не работает. Я пробовал запускать с --print-gc-sections - получалось, что без --no-gc-sections, в логе была эта удаленная секция, а с нет. Не понимаю, на каком этапе линкер ее удаляет.
источник

MV

Mikhail Voronov in pro.cxx
Судя по сорцам https://github.com/llvm/llvm-project/blob/main/lld/wasm/MarkLive.cpp он как раз не удаляет тут секции, если есть этот флаг
источник

DF

Dollar Føølish in pro.cxx
Mikhail Voronov
Вообще странно, что флаг --no-gc-sections линкера не работает. Я пробовал запускать с --print-gc-sections - получалось, что без --no-gc-sections, в логе была эта удаленная секция, а с нет. Не понимаю, на каком этапе линкер ее удаляет.
Помимо Гц секций ещё лто может удалять  секции
источник

MV

Mikhail Voronov in pro.cxx
Хм, спасибо, сейчас посмотрю на сорцы
источник

DF

Dollar Føølish in pro.cxx
Я чёт подумал а ведь правда если в дефолтном линкер скрипте нету вашей секции то она и не попадет в бинарь
источник

FS

Flower Surgeon in pro.cxx
Mikhail Voronov
а никто случайно не пробовал генерировать кастомные секции для васма? Я пытаюсь сделать как-то так

const unsigned char __FCE_SDK_VERSION[6] __attribute__((section(".custom_section.__fce_sdk_version"))) = "0.5.0";

но даже с --no-gc-sections в результирующем васм бинарнике её не появляется
источник

MV

Mikhail Voronov in pro.cxx
так тоже не работает, похоже секция обрезается ещё до линкера, в .ll файле её нет
источник

MV

Mikhail Voronov in pro.cxx
хотя нет, это я искал !wasm.custom_sections, как здесь https://github.com/llvm/llvm-project/blob/62ec4ac90738a5f2d209ed28c822223e58aaaeb7/lld/test/wasm/custom-sections.ll#L15

а она есть в "обычном" виде
@__FCE_SDK_VERSION = hidden constant [6 x i8] c"0.5.0\00", section ".custom_section.__fce_sdk_version", align 1
источник

t

text in pro.cxx
а тут знает кто почему первое заполнение массива медленнее повторного
источник

BU

Boris Usievich in pro.cxx
потому что в процессоре есть кэш
источник

t

text in pro.cxx
а где почитать про взаимодействие кеша с программой
источник

t

text in pro.cxx
за счет чего более быстрые обращения к памяти
источник

MK

Mikhail Kalugin in pro.cxx
text
за счет чего более быстрые обращения к памяти
За счет того что, что процессор вообще не обращается к памяти во второй раз (кусок памяти с массивом уже в кэше).
источник