то есть хочу вырезать дерево вызовов функций и обращений к глобальным данным из этой либы.
то есть в неком .с файле вызывается функция из этой либы и она что-то вызывает еще и т.д.
эта функция не main()
можно ли сделать так, чтобы не линковался экзешник, а некий промежуточный объектник, в который вошли бы только вызываемые функции, а остальная часть библиотеки не использовалась?
или хотя бы всю либу засунуть в этот объектник, секретность или уменьшение размера не сильно важно
----------------
после этот объектник слинкуют со своим кодом (там main()) некие юзера
какого-то особого смысла тут нет, человеческий фактор - не могут либу прикрутить к флоу, а объектник могут (какая-то гуи, куда вписать gcc-шные ключи не нашли)
Полная версия этой страницы: как из статической либы в объектник выдернуть функции?
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > GNU/OpenSource средства разработки
может проще научить этих деятелей линковать либы при сборке... это какбы избавит от подобных проблем в будуюшем.
по сущесьвк. либу можно распотрошить на объектники из которых она составлялась
ar -x lib_name.a
по сущесьвк. либу можно распотрошить на объектники из которых она составлялась
ar -x lib_name.a
Цитата(yes @ Nov 15 2012, 17:51) 
можно ли сделать так, чтобы не линковался экзешник, а некий промежуточный объектник, в который вошли бы только вызываемые функции, а остальная часть библиотеки не использовалась?
«Нутром чую, но доказать не могу», что надо смотреть в сторону линкеровского ключа -rЦитата
-r
--relocatable
Generate relocatable output—i.e., generate an output file that can in turn serve as input to ld. This is often called partial linking.
--relocatable
Generate relocatable output—i.e., generate an output file that can in turn serve as input to ld. This is often called partial linking.
проблема оказалась слегка похуже, разные компилеры sparc-rtems- и sparc-elf- вроде бы из одних исходников собирались (Гейслером), но libc наверно разная (а может и интерналсы какие типа libgloss), вобщем "нахаляву" не получилось.
переписываю сейчас некоторые куски, которых там нет и собираю другим компилером.
вопрос остался интересен теоретически...
переписываю сейчас некоторые куски, которых там нет и собираю другим компилером.
вопрос остался интересен теоретически...
Цитата(yes @ Nov 19 2012, 18:18)
проблема оказалась слегка похуже, разные компилеры sparc-rtems- и sparc-elf- вроде бы из одних исходников собирались (Гейслером), но libc наверно разная (а может и интерналсы какие типа libgloss), вобщем "нахаляву" не получилось.
Извините, не понял. Что именно не получилось? И почему вы вообще говорите о компиляторах, если вопрос был о линковке?
Цитата(yes @ Nov 15 2012, 19:51)
то есть хочу вырезать дерево вызовов функций и обращений к глобальным данным из этой либы.
то есть в неком .с файле вызывается функция из этой либы и она что-то вызывает еще и т.д.
то есть в неком .с файле вызывается функция из этой либы и она что-то вызывает еще и т.д.
Во первых Есть плагин к FAR который парсит elf файлы. таким образом статические библиотеки для фара -- папка со списком объектных файлов.
Во-вторых при линковке вы должны просто линковщику подать на вход список статических библиотек, он сам должен выдрать нужные функции.
Цитата(alx2 @ Nov 20 2012, 14:09)
Извините, не понял. Что именно не получилось? И почему вы вообще говорите о компиляторах, если вопрос был о линковке?
вопрос возник потому, что моя библиотека не подлинковывалась к чужому проекту, хотелось минимально напрягаться для решения (мне казалось, что объектник вместо библиотеки - решение), также было подозрение, что, кроме моей либы, libc разная и какие-то функции в полном дереве нужно вытягивать и из нее
так как выяснилось, что это не типовая задача и ответа я не получил, то пришлось переделать исходники, надергать в них куски из libc (она тоже в исходниках) и т.д.
я не эксперт по компиляторам (скорее железячник, чем программист), но понимаю так : gcc требует libc, и еще несколько библиотек, которые не требуется даже указывать с -l линковщику
в конкретном sparc-*-gcc в эти библиотеки входит даже 2-3 RTOS | context switch-a, которые можно вызывать без подключения библиотек - это bare switch от Гейслера, freertos и pthread (? может им нужна библиотека типа -lpthread никогда не пользовал)
для конфигурируемых ecos или rtems собирается "ядро" в виде библиотеки и подключается. наверно, sparc-rtems-* содержит более простую версию поддержки железа (перекладывает это на "ядро"), то есть не хватало как раз лоу-левел функций типа управления прерываниями, манипуляций с кэшем и регистровыми окнами и т.п...
то есть все это специфично и разбираться в деталях мне не хочется,
---------------
но если есть универсальный метод в gcc/binutils-ах для манипулирования объектниками - мне хотелось бы знать, вдруг пригодится
Цитата(SyncLair @ Nov 20 2012, 19:28)
Во первых Есть плагин к FAR который парсит elf файлы. таким образом статические библиотеки для фара -- папка со списком объектных файлов.
Во-вторых при линковке вы должны просто линковщику подать на вход список статических библиотек, он сам должен выдрать нужные функции.
Во-вторых при линковке вы должны просто линковщику подать на вход список статических библиотек, он сам должен выдрать нужные функции.
по моему FAR это левак
, ну то есть манипулировать elf-ами можно и самому, но хотелось бы стандартного методалинковку производила "третья сторона" и линковщик ругался на отсутствие нужных функций, то есть мой вопрос можно сформулировать так : возможно ли часть линковки провести в одном окружении (с неким набором библиотек), а потом передать этот "частично слинкованый" объект для окончательной линковки в исполняемый файл ??
Цитата(yes @ Nov 21 2012, 19:15)
я не эксперт по компиляторам (скорее железячник, чем программист), но понимаю так : gcc требует libc, и еще несколько библиотек, которые не требуется даже указывать с -l линковщику
в конкретном sparc-*-gcc в эти библиотеки входит даже 2-3 RTOS | context switch-a, которые можно вызывать без подключения библиотек - это bare switch от Гейслера, freertos и pthread (? может им нужна библиотека типа -lpthread никогда не пользовал)
в конкретном sparc-*-gcc в эти библиотеки входит даже 2-3 RTOS | context switch-a, которые можно вызывать без подключения библиотек - это bare switch от Гейслера, freertos и pthread (? может им нужна библиотека типа -lpthread никогда не пользовал)
Не совсем так. Он не то чтобы "требует", просто он заранее знает некоторые библиотеки (например libc, libgcc). Но это ему можно запретить опциями -nodefaultlibs/-nostdlib. Ничто не мешает собрать проект с той libc (libm, libpthreads и т.п.), с какой хочется (а не той, которую "знает" gcc).
Цитата(yes @ Nov 21 2012, 19:15)
но если есть универсальный метод в gcc/binutils-ах для манипулирования объектниками - мне хотелось бы знать
Довольно универсальный метод - это objcopy (плюс objdump для их просмотра).
Цитата(yes @ Nov 21 2012, 19:15)
возможно ли часть линковки провести в одном окружении (с неким набором библиотек), а потом передать этот "частично слинкованый" объект для окончательной линковки в исполняемый файл ??
Да, возможно. Но упомянутый Вами "некий набор библиотек" должен совпадать (если эти библиотеки используются и у Вас, и у третьей стороны).
Пример:
CODE
alx% cat test1.c
#include <stdio.h>
void f1(void)
{
printf("f1()\n");
}
alx% cat test2.c
#include <stdio.h>
void f3(void);
void f2(void)
{
printf("f2()\n");
f3();
}
alx% gcc -O2 -static -Wl,-r -o test12.o test1.c test2.c
alx% cat test3.c
#include <stdio.h>
void f1(void);
void f2(void);
void f3(void)
{
printf("f3()\n");
}
int main(void)
{
printf("main()\n");
f1();
f2();
}
alx% gcc -O2 -static -nostdlib -o test test3.c test12.o
alx% ./test
main()
f1()
f2()
f3()
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.