Средства и методы разработки

Не понял вопроса. В линуксах всегда PIC код для библиотек (они ж в разных процессах могут по разным адресам попадать). Доступ к данным и коду ведётся через GOT (и PLT для функций). GOT конструируется в момент загрузки (и он большой!). Адрес GOT вычисляется из какого-либо регистра. Например для MIPS ABI заставляет все вызоты делать через помещение в $t9 адреса функции и jalr $t9. Тогда в вызванной функции t9 содержит её собственный адрес. Зная свой адрес (в момент компиляции не знает -- её ж загрузят фиг знает куда, для того и PIC-код) и его смещение относительно GOT легко вычислятеся адрес последнего... Подход как в linux для мелких МК не очень эффективен. Например, можно не хранить массу адресов в GOT, а использовать относительные адреса (для кода и rodata). Такой подход используется в nuttx. Там для того специально пропатченный gcc используется. Ну а данные относительно специального регистра адресуют (который компилятором не трогается никогда). На работе аналогичное есть, но там вместо патченного gcc используют перловый скрипт, который парсит ассемблерные тексты от компилятора, находит там обращения к GOT, и заменяет на более короткий набор инструкций косвенной адресации. В общем рекомендую ознакомиться с вопросом как оно решается в nuttx (а то и целиком его использовать). Подход с GOT хорош для больших операционок, а для мелкого МК избыточен. Кроме того нужен загрузчик elf файлов в твоей недоОС. А libc что мешает пересобрать? newlib тот же. Хотя он тяжеловесен. Есть более миниатюрные реализации. По крайней мере если ввод-вывод перекрыть своими функциями (из stdio.h), то libc становится легче раз в несколько (тебе ж только sprintf и sscanf простейшие нужны, а не поддержка юникода в болгарской локали...)