LINUX.ORG.RU

Затянувшийся спор с разработчиком ld

 ,


0

3

Наблюдаю сейчас затянувшийся спор разработчика загрузчика системы Limine с разработчиком binutils по поводу какого-то изменения в ld, а конкретнее в Binary File Descriptor library (BFD). Это изменение приводит к настандартному (по мнению разраба Limine) поведение ld. Конкретнее если слинковать static-pie kernel при помощи ld тип получаемого ELF файла может быть разным: ET_DYN если адрес загрузки начинается с нуля или ET_EXEC в противном случае. При этом ld.lld и ld.gold в обоих случаях генерируют только ET_DYN. В ходе спора выяснилось, что это нестандартное поведение появилось в ld около десяти лет назад, как хак какой-то проблемы с тогдашним ядром Linux. Разработчик Limine просит изменить это поведение или хотя бы добавить возможность изменить его на более стандартное при помощи дополнительного параметра запуска ld. Разработчик ld не хочет этого делать и вместо этого закрыл баг после небольшой правки документации:

--- a/ld/ld.texi
+++ b/ld/ld.texi
@@ -2694,7 +2694,10 @@ Same as @option{--section-start}, with @code{.bss}, @code{.data} or
 @item -Ttext-segment=@var{org}
 @cindex text segment origin, cmd line
 When creating an ELF executable, it will set the address of the first
-byte of the text segment.
+byte of the text segment.  Note that when @option{-pie} is used with
+@option{-Ttext-segment=@var{org}}, the output executable is marked
+ET_EXEC so that the address of the first byte of the text segment will
+be guaranteed to be @var{org} at run time.

https://sourceware.org/bugzilla/show_bug.cgi?id=31795

Как по-вашему, кто из них прав и почему?


Ответ на: комментарий от no-such-file

Причём тут всё это? У ld есть нестандартное поведение с ELF файлами, являющееся костылём. Никто кроме ld так не делает и поэтому вполне логичным было бы если и не выпилить этот костыль нафиг, то по крайней мере, сделать его отключаемым. Но для этого разрабы ld или BFD должны по крайней мере согласиться с этим. Потому что иначе даже полностью готовый патч просто выкинут на холод.

zg
() автор топика
Ответ на: комментарий от zg

Никто кроме ld так не делает

Кто никто? Ты ж тут втираешь что больше никого и нету, одни недоделки и проприетарный мусор.

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

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от no-such-file

Кто никто?

Я уже говорил: ld.gold и ld.lld

Ты ж тут втираешь что больше никого и нету, одни недоделки и проприетарный мусор.

Ничего такого я не втираю, перечитай.

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

Почему в тебе так много токсичного негатива? Человек пытается сделать мир лучше, а ты хоботом ворочишь.

zg
() автор топика
Ответ на: комментарий от anonymous

да. ждём x86S

Скорее всего нас ждёт всеобщий переход на ARM. Но только, если кто-то догадается не жмотиться и сделает архитектуру ARM-PC открытой, как в своё время IBM-PC.

zg
() автор топика
23 октября 2024 г.
Ответ на: комментарий от zg

Но для этого разрабы ld или BFD должны по крайней мере согласиться с этим.

Как я понял, придётся патчить ещё и глибц. Так что соглашателей нужно довольно много набрать.

anonmyous ★★
()
Ответ на: комментарий от zg

Скорее всего нас ждёт всеобщий переход на ARM. Но только, если кто-то догадается не жмотиться и сделает архитектуру ARM-PC открытой, как в своё время IBM-PC.

А куда уж открытее? Всё, что сейчас на армах делается (кроме эпплов), чуть ли ни со схематикой поставляется. Даже если где-то есть вендорные блобы, то где-то ещё - есть и их открытые реализации почти всегда.

anonmyous ★★
()
Ответ на: комментарий от wandrien

Если не загнётся, то RISC-V обрастёт такими же костылями, что и ARM. Дайте ему лет 20.

В АРМ вложено такое бабло, что риск5 и за 20 лет их не догонит. Кто в него столько вложит?

anonmyous ★★
()