Ах , да, ещё и ldl придется пропатчить штоб оно могла dlsym по таким библиотекам делать

А оно уже часть libc

Ну и главное это ртлд ld-linux.so должен уметь в это аби

Возможно я преувеличиваю , но проблема бинарных библиотек примерно такого решения требует

хм, а можно ли к существующему аби добавлять фичи, не меняя и не удаляя имеющиеся? Так, чтобы старые линкеры умели с такими либами ограниченно работать, а новые - уже полноценно?

Ну метки это все что текущие линкеры понимают

Они и дебаг инфо просто копируют из одного объектника в другой

Штоб какие нибудь c++ классы оно понимало ,боюсь придется новый Бин формат создавать

Простых сегментов с секциями недостаточно будет наверное

да не, это заведомо нереально. Идея расширить abi имеющихся компиляторов Си. И очень хочется придумать шаблоны/мономорфизируемые дженерики, которые можно оттуда цеплять

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

Моя любимая шутка

@nlinker @ibxth что думаете?

я вот только хз, можно ли так расширить, чтобы оставалась совместимость с линкерами,  работающими с c abi?

Я бы сказал неудачная инициатива и не только потому, что уже есть легионы софта, который завязан на сишный ABI.
Это чертовски весомая причина (легаси), но также дело в другом: как только появится спецификация на передачу расширенной информации о типах, которая каким-то образом окажется модульной и покрывающей распространённые варианты использования, тотчас найдутся десятки вариантов "расширений расширения", чтобы покрыть ещё какой-нибудь случай, возникший в недрах какого-нибудь гугла.

Вроде как можно посмотреть как сделать систему модулей с богатым интерфейсом (можно глянуть тот же backpack из Haskell), но тут возникает ещё одна проблема: что если в каком-то из языков будет типизация, которая не вкорячивается в этот ABI? Подобный пример был в случае Скалы когда там ещё не было экзистенциальных типов, а в Джаву уже вкорячили вайлдкарды (такие странные дженерики). И Скалу пришлось наворачивать, чтобы по меньшей мере получить джавовскую систему типов как частный случай Скалы. То есть проблема была в том, что Java расширила свой ABI несовместимым для Скалы образом.

Не стоит забывать также, что кроме нативных пользователей этого нового гипотетического ABI (C, C++, Rust) есть и множество других языков вроде того же Питона и Го, которым надо будет как-то делать FFI.

Да почему ты меня тэгаешь? Я далёк от этого. Я только раст знаю и то довольно поверхностно.

>легионы софта, который завязан на сишный ABI
так идея заключается в том, чтобы оставить совместимое подмножество. Или проблема в чём-то другом?

>возникший в недрах какого-нибудь гугла.
пускай делают, вряд ли дальше Гугла это пойдёт. А если и пойдёт, то и ладно -никто же не пытается опираться на C++ ABI. И тут вряд ли будет...

>что если в каком-то из языков будет типизация, которая не вкорячивается в этот ABI
тогда придётся отказаться от такой типизации. Должна быть обеспечена совместимость

>Java расширила свой ABI несовместимым для Скалы образом
не совсем понял суть проблемы, но всегда же можно ограничиться максимально допустимым подмножеством.   Условно говоря, ограничиться поддержкой Java 7, а на Java 8 забить. А если нет ощущения мощи за языком (за Scala), то придётся либо подстраиваться, либо перепиливать язык, чтобы получилось "хорошо".

кажется, ты неплохо разбираешься в этих низкоуровневых штуках. Или я ошибся?

Ошибся. Уже не первый раз. Я в них не особо разобрать.

Зачем?