FreePascal и PIE

[Alexander]

В новую экспериментальную версию органайзера включил FPC из GIT и включил в нем PIE. Это в целом удалось.
Основные изменения в i_linux.pas (включением tf_pic_default) и t_linux.pas :

Код: Выделить всё

     ExeCmd[1]:='ld -lc --pie --dynamic-linker=/lib64/ld-linux-x86-64.so.2 '+platform_select+platformopt+' $OPT $DYNLINK $STATIC $GCSECTIONS $STRIP $MAP $LTO $RPATH -L. -o $EXE';
     DllCmd[1]:='ld -lc --pie --dynamic-linker=/lib64/ld-linux-x86-64.so.2 '+platform_select+platformopt+' $OPT $INIT $FINI $SONAME $MAP $LTO $RPATH -shared $GCSECTIONS -L. -o $EXE';


Такие изменения можно было бы включить в ФПК по умолчанию для Линукс, ведь PIE давно (много лет) является требованием дистрибутивов, а не рекомендацией.

http://soft.self-made-free.ru/GORG64_64.tar.xz

Также в. deb включены fpc (заменяет системный !), mseide, ideu, dr и воспроизведение формата midi.
Добавлен скрипт для возможности упреждающего закрытия FireFox преред выключением(перезагрузкой) компьютера в связи с https://bugzilla.mozilla.org/show_bug.cgi?id=1837907.
И ещё некоторые.

[Сквозняк]

А с путями то в линуксе- что? Вдруг в нём не будет симлинка /lib64 или FPC 32 битный.

[Alexander]

Ну, видимо, ifdef'ами или сложным патчем во время компиляции. Я решил это только для: Linux, Debian, x86_64. Это не такой простой вопрос.
Собственно PIE и включили с появлением x86_64 (в 64 битных процессорах это сделано специально и удобно и рекомендовано к применению, что и дало толчок в этом направлении), до этого его особо и не было.
Опять же ядро запускает и с PIE и без - это только устройство современного дистрибутива.
То, что в некоторых дистрибутивах может быть иное расположение /lib64 и нет стандарта на это плохо, но и там можно просто создать симлинк да и всё, а это решение.
При отсутствии стандартного расположения в каждой инсталляции может быть в принципе своё расположение. При желании можно собрать коллекцию расположений со своих инсталляций и описать ifdefами.
Проблемы не только с 32 битами и разным расположением,/lib64 - это скорее ifdefами, симлинком и патчами и решается, но и в коде затем ассемблерные вставки нужно писать иначе (rip-relative).
Но это вопрос уже дальнейшего творчества и фантазии. Переход на PIE довольно серьёзный переход и прогрессивный, но он давно назрел. Тем не менее для актуальных 64 бит я его включил.

[Сквозняк]

А что с ним в паскале можно делать?

[Снег Север]

"О! Мсье знает тольк в извращениях..." (С)

[Alexander]

> А что с ним в паскале можно делать?

Это только усложняет задачу для программиста. Как только PIE включен - без PIE становится писать невозможно, до включения можно писать и так, и так.
То есть без PIE можно было написать и

Код: Выделить всё

mov p, rax

, а с PIE только

Код: Выделить всё

mov [rip+p], rax

(p : Pointer;).
Ну и некоторые приёмы программирования в синтаксисе Паскаля могут не пройти, хотя в целом ещё неплохо включилось (ключ -Cg, включающий PIC существует достаточно давно).
С точки зрения программиста на Паскале для включения PIE нужно переписать код до достижения совместимости с ним.

Поскольку Паскаль имеет встроенный ассемблер включить в нём PIE несколько сложнее, чем в Си.
А преимущество в самом PIE - такую программу пустят в дистрибутив. Это особенности кодогенерации.
Дистрибутив же получит возможность динамически распоряжаться независимыми фрагментами кода, которыми до включения PIE он распоряжаться не мог. В частности для повышения безопасности.
Сама адресация rip+... и её свойства и преимущества с точки зрения машинного кода описана в pdf документации на AMD X86_64 процессор, которую можно скачать с сайта amd.

> "О! Мсье знает тольк в извращениях..." (С)

Не, как раз без извращений. Раз дистрибутив требует с PIE, то извращением является неиспользование его. Но да, задача усложняется.

[Alex2013]

PIE(Position Independent Executables)? В чем вообще его глубокий смысл ? (Если я верно понял это про исполняемый код выше 4 гигов что вообще не очень непонятно при линейной модели памяти. Вроде при ней каждому приложению выделяется минимум по 4 гига адресного пространства при 32-битном режиме и заметно больше при 64-битном ... Или я что-то путаю? )
Зы
Сразу вспоминаются мои "лихие" попытки писать "внешнюю навесную защиту" EXE-файлов для DOS с полностью самодельным загрузчиком где-то в мохнатых 90-х.

[Сквозняк]

О как, оказывается. Пару дней считал, что речь идёт про подключение к паскалю пролога

[Снег Север]

А преимущество в самом PIE - такую программу пустят в дистрибутив

Дистрибутив чего? Зачем мне в дистрибутив?

[Alexander]

> Или я что-то путаю?
ну да, это PIE, а выше 4 gb это:
Physical Address Extension (PAE)

PIC --> PIE позволяет динамическому загрузчику системы произвольно перетасовать секции ELF файла.
Это не связано с адресацией большой памяти, а адресацией относительно регистра-указателя команд (IP, для 64 бита это rip), затем специальным способом собираются секции файла.
То есть метка или адрес функции при этом задаётся не константой адреса, а количеством байт относительно rip: больше или меньше rip на столько-то байт.
Такой фрагмент кода независим от конкретных адресов и может быть перемещён по другому адресу динамическим загрузчиком.
Компилятор делает PIC, а линковщик собирает его в PIE. Паскаль сегодня умеет PIC, но не умеет PIE.

> Зачем мне в дистрибутив?

Сам Паскаль исчезнет, если его не будут пускать в дистрибутив. На сегодня ни Паскаль, ни программы на нём написанные не проходят эту системную проверку исполняемых файлов (например lintian).

[Сквозняк]

Подключение PIE влияет только на ассемблерные вставки и менеджеры памяти, а на простые функции и операции нет?

[Alexander]

На ассемблерные вставки в первую очередь - их после этого нужно писать специальным способом. А остальное более-менее готово к PIE.
Для программиста простые функции и операции проходят при этом прозрачно, но конечный код и их всё равно будет в PIE. Если хоть один оператор во всей программе не PIC - компиляция в PIE не удастся.

[Сквозняк]

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

[Alexander]

Встроенный ассемблер есть, часть Си уже к Паскалю прикрутили (операторы Си, полиморфизм, ....), но можно и Пролог добавить. Это возможно. В этом будет толк - будут декларации. Но также можно заодно и Icon - будут длинные числа, можно Питон и будет искусственный интеллект, можно добавить forth и будет простота и компактность, Фортран - будет математика, Maxima - будут символьные вычисления и так далее. Идея всё равно правильная его туда добавить.

[Alex2013]

можно Питон и будет искусственный интеллект

Это точно есть...
https://github.com/pyscripter/python4delphi
Правда сомневаюсь что там вот так сразу будет ИИ... ( сильно сомневаюсь что python4delphi поддерживает CUDA или хотя-бы OpenCL )
То что всякие SD и ChatGPT реализованы на питоне не означает что питон "специализирован для ИИ".
(Фак то что Питон это современный "научный язык" ну так ранее таковым был например тот-же Qbasic )