Скорее всего я не понимаю, что именно Вы этим abi считаете.
вызывало функцию printf из ядра ОС и могло быть как вкомпилировано в ядро, так и запущено извне.
Это очень странное требование. Ядро не должно не то что вызывать printf и подобные ей, но и даже ничего о ней не знать. По хорошему, каждое приложение и динамическая библиотека должны иметь собственную реализацию таких функций как printf и использовать для вывода API ядра. Но если Вас интересует именно динамическая линковка библиотеки с набором стандартных функций (для экономии памяти приложений и библиотек, и это правильно), то достаточно один раз их обернуть в функции «заглушки» и в статической библиотеке (для автоматической линковки dll) прописать их уже реальные названия получив позиции «заглушек» из динамической таблицы.
А если серьёзно, то Вы так и не назвали в чём именно состоит проблема, кроме как отговорки, что типа сложно и никто так не делает и мы тогда тоже не будем. Если бы было сказано, что это попросту Вам, да и вообще никому не нужно, то и вопросы сразу же отпали бы.
ELF или EXE файлов. Мне кажется, Вас там ждет новая информация.
Читаем из нашей любимой википедии:
Файлы PE не содержат позиционно-независимого кода. Вместо этого они скомпилированы для предпочтительного базового адреса, и все адреса, генерируемые компилятором/компоновщиком, заранее фиксированы. Если PE-файл не может быть загружен по своему предпочтительному адресу (потому что он уже занят чем-то ещё), операционная система будет перебазировать его.
Это отличает формат PE от ELF, который использует полностью позиционно-независимый код и глобальную таблицу смещений, которая жертвует временем выполнения в пользу расходования памяти.
Всё верно, как и предполагалось.
Видимо определение слова удобно у нас с Вами тоже не совпадают.
Да это удобно, разве нет?
Вот так вот просто берем и делаем, да?
Да, и ОС предоставит нам для этого все необходимые интерфейсы.
Если у Вашего МК нет MMU -> uCLinux
Как то вяло он разрабатывается. И зачем нам линукс на мк если от него там только одно название и останется.
Виртуальные адреса не совпадают у разных библиотек загружаемых в один процесс.
Физические адреса тоже не совпадают, иначе мы бы не смогли их держать в памяти одновременно. Процесс заранее не знает где будут библиотеки до их линковки. Это в точности повторяет работу МК без виртуальной памяти.
В этом и состоит суть концепции виртуальной памяти — с точки зрения процесса он исполняется на устройстве монопольно.
Так же как и процесс на МК, тоже не знает о существовании других процессов. Ведь он точно так же не имеет права исполнять, писать и читать то чего ему не выделили.
разные процессы, скомпилированные в расчете на виртуальную память будут каждый ожидать разное содержимое одних и тех же виртуальных адресов.
Это не так, процессы работают только с той памятью о которой им сообщат динамически, т.е. им заранее ничего не известно. Только часть заранее загруженных библиотек API у всех процессов совпадают в VM, и только по тому что процесс их линковки при запуске одинаков для всех, не более.
Ничего не мешает, но это уже не динамическая линковка.
Динамичнее уже некуда.
физическое адресное пространство не резиновое.
1ГБ как минимум можно примапить к МК, гуляй сколько хочешь.
использование Position-Independent code… НО это работает с рядом оговорок
Можно услышать хоть одну внятную оговорочку?
Платформа очень широкое понятие, в отличие от архитектуры, и в нашем контексте не уместно.
Таблица относительных адресов функций (интерфейсов динамической библиотеки) будет весить 4*N байт, где N — количество импортируемых функций. Находится она в самой библиотеке. Для вызова достаточно хранить в ОЗУ только 4 байта (на одну либу) с адресом положения этой таблицы.
Ну мы обычно просто задачи с равным приоритетом делаем как раз, чтобы они друг друга не вытеснили и спокойно доделали своё дело.
Всё верно, подход требует правильного проектирования взаимодействия между задачами. По сути они должны всё знать друг о друге, что бы получить максимальный эффект для производительности.
Если задачи имеют одинаковый приоритет, то пока не выполнится одна, вторая не запустится, но тоже самое будет и у вас, пока вы не поставите, что то типа Sleep
Вытесняющий планировщик разделит время на все процессы с одинаковым приоритетом (условно по 10млс на задачу), даже если там будет бесконечный цикл, всё равно всем достанется. При вашем варианте будем ждать тяжёлый процесс из этой группы. Но этот метод действительно экономный и при правильном проектировании даёт значительные преимущества.
Но там есть несколько других проблем, например синхронизацию между потоками типа мьютексов так просто не сделать
Если сочетать оба метода планирования, например ваш метод внутри вытесняющего планировщика в рамках одного процесса, позволит сэкономить на создании в нем потоков(нитей). И синхронизацию можно упросить, если использовать с этим методом только те функции которым она не требуется (или не создаёт проблем).
Принцип работы такой же как и у стандартных прерываний? Тогда если будет несколько задач (больших и маленьких) с одинаковыми приоритетами то в этот момент многозадачность становится кооперативная для этой группы.
Это некорректное утверждение. Загрузка двух динамических библиотек для одного процесса не будет никогда произведена на одни и те же виртуальные адреса.
Ага, значит виртуальные адреса никогда не совпадают, и при этом они также загружены в разные физические участки RAM. Так что нам мешает в МК прилинковать не к виртуальным а к физическим и MMU нам и не понадобился.
Если Вы заранее знаете весь набор приложений
Набор всех приложений не известен.
Это к разговору о динамической линковке точно не относится.
Эти приложения могут находится в разных участках памяти и к ним нужно прилинковать ОС которая тоже может находится где угодно.
попытки написать что-то универсально кросс-платформенное
Если Вы попытаетесь загрузить ее и «слинковать» вручную, то Вам каким-то образом нужно будет перехватить все запросы к адресам в блоке Х и подменить адреса так, чтобы они ушли в блок Y с корректными смещениями. Если у Вас есть MMU, то это тривиально.
MMU это не устройство, которому требуется «перезагружаться» от библиотеки к библиотеки.
Эти два утверждения не вяжутся. Т.к. динамические библиотеки не знают о существовании друг друга, то их виртуальные адреса будут совпадать, а MMU мы не перезагружаем то он накладываются.
Самый главный вопрос тут: а что Вам вообще с Вашей точки зрения даст динамическая линковка, если Вам нужно чтобы «все одновременно»?
Я хочу написать приложение для МК и не знать что там вообще происходит с другими процессами, если есть под мою программу место то — запускается, если нет то сообщить о недостатке памяти. А также хочу скомпилировать её один раз и чтобы она работала на всех МК с архитектурой ARMv7-M и ARMv8-M (Mainline). Как то так.
Это очень странное требование. Ядро не должно не то что вызывать printf и подобные ей, но и даже ничего о ней не знать. По хорошему, каждое приложение и динамическая библиотека должны иметь собственную реализацию таких функций как printf и использовать для вывода API ядра. Но если Вас интересует именно динамическая линковка библиотеки с набором стандартных функций (для экономии памяти приложений и библиотек, и это правильно), то достаточно один раз их обернуть в функции «заглушки» и в статической библиотеке (для автоматической линковки dll) прописать их уже реальные названия получив позиции «заглушек» из динамической таблицы.
Всё таки можно. Тогда продолжаем.
Здесь могу предложить сделать всё наоборот.
Тогда нужно использовать стандарт abi для ARM.
А если серьёзно, то Вы так и не назвали в чём именно состоит проблема, кроме как отговорки, что типа сложно и никто так не делает и мы тогда тоже не будем. Если бы было сказано, что это попросту Вам, да и вообще никому не нужно, то и вопросы сразу же отпали бы.
Читаем из нашей любимой википедии:
Всё верно, как и предполагалось.
Да это удобно, разве нет?
Да, и ОС предоставит нам для этого все необходимые интерфейсы.
Как то вяло он разрабатывается. И зачем нам линукс на мк если от него там только одно название и останется.
Они не будут так скомпилированы если им этого не позволять.
Давно где то читал, где — уже не вспомню.
Согласен, это бессмысленно и не нужно.
Мне так кажется более удобно и экономично при переиспользовании повторяющегося кода для приложений которые компилируются независимо.
Хорошо, делаем их такими где требуется.
Хочу полноценную ОС для МК без виртуальных машин.
Так же как и процесс на МК, тоже не знает о существовании других процессов. Ведь он точно так же не имеет права исполнять, писать и читать то чего ему не выделили.
Это не так, процессы работают только с той памятью о которой им сообщат динамически, т.е. им заранее ничего не известно. Только часть заранее загруженных библиотек API у всех процессов совпадают в VM, и только по тому что процесс их линковки при запуске одинаков для всех, не более.
Динамичнее уже некуда.
1ГБ как минимум можно примапить к МК, гуляй сколько хочешь.
Можно услышать хоть одну внятную оговорочку?
Платформа очень широкое понятие, в отличие от архитектуры, и в нашем контексте не уместно.
Если сочетать оба метода планирования, например ваш метод внутри вытесняющего планировщика в рамках одного процесса, позволит сэкономить на создании в нем потоков(нитей). И синхронизацию можно упросить, если использовать с этим методом только те функции которым она не требуется (или не создаёт проблем).
Набор всех приложений не известен.
Эти приложения могут находится в разных участках памяти и к ним нужно прилинковать ОС которая тоже может находится где угодно.
Здесь общая архитектура, а не платформа.