2015-04-29 3 views
2

У меня есть унаследованная система, которая объявляет символы в области разделяемой памяти. Адреса из них статически определены в абсолютных адресах в памяти с помощью функции сценария командной строки gcc. Я могу создать статический тестовый исполняемый файл в C, который правильно ссылается на эти символы, когда я передаю скрипт статического объекта и скрипт командной строки во время компиляции и присоединяюсь к области разделяемой памяти (shmat() и т. Д.).Устранение статически определенных символов в общей библиотеке

То, что я пытаюсь сделать, это построить библиотеку расширений Python, которая может обращаться к тем же символам. Возможность доступа к библиотеке из Python требует от -shared и -fPIC вариантов из того, что я понимаю. Когда я компилирую этот путь, символы больше не располагаются на правильных адресах. Компиляция тестовой программы C с -shared -fPIC также приводит к неправильным адресам. я могу определить символы в библиотеке расширения непосредственно:

int *pA = 0x030A0000; 

и это работает при компиляции с использованием -shared -fPIC. Но должен ли я? Есть сотни символов, которые мне нужны, и это было бы немыслимо, если бы адреса когда-либо менялись. Похоже, что там должен быть способ, чтобы указать компоновщику, что эти символы не должны быть переселены, но я ничего не имею tried имеет worked, включая составление, как показано ниже:

В коде для расширения Python:

extern int symbol_i_need; 
... 
printf("%d", symbol_i_need); // Seg fault 

Вкомпилировать команды:

gcc -fPIC -o my_module.o my_module.c /path/static_object.o /path/linker_command_script.ld 
gcc -shared -fPIC -o my_module.so my_module.o -Wl,-Bstatic,/path/static_defined_object.o,/path/linker_command_script.ld,-Bdynamic -rdynamic 
+0

'PIC' означает« Position Independent Code »и указывает компоновщику, что он может воспользоваться функцией из библиотеки и разместить ее в любом месте раздела кода памяти. Возможно, я не так быстр, как и многие другие, но кроме того, что вы делаете, у меня действительно нет решения. – jiveturkey

+0

Да, я прочитал описание флага на странице руководства, и он поднял с меня несколько предупреждающих флагов. Тем не менее, я использую distutils для создания модуля Python, и флаг вставлен автоматически. Мое предположение заключалось в том, что модуль должен правильно работать с Python, но я сделаю некоторое расследование. –

ответ

0

После исследования и долгих экспериментов с различными флагами (--just-symbols, -Bsymbolic, --dynamic-list, --defsym и т. Д.), И с помощью theseanswers и objdump и некоторых printf я обнаружил, что способ, которым обмениваемые объекты индексируют свои символы, не позволяет получить результат. Невозможно скомпилировать желаемое расширение Python в качестве общего объекта без ручной настройки указателей на все необходимые символы.

Что мне удалось сделать, это добавить тот же код модуля, который я написал во встроенные модули Python. Перекомпиляция Python с моим настраиваемым модулем там и связь с файлами статических объектных файлов и компоновщика, которые у меня уже были (добавлены в файл Modules/Setup: my_module my_module.c -I/include/path -Xlinker /path/static_object.o /path/linker_script.ld), позволили всем символам разрешить их правильные адреса. Документации в источнике Python было достаточно, чтобы показать мне, как это сделать.

 Смежные вопросы

  • Нет связанных вопросов^_^