dlopen для нового двоичного файла с тем же именем возвращает старый дескриптор - PullRequest
Новая
       27

dlopen для нового двоичного файла с тем же именем возвращает старый дескриптор

0 голосов
/ 20 мая 2018

Я использую dlopen для загрузки динамически сгенерированного кода.Программа вызывает компилятор кода и генерирует файл .so, который затем загружается программой для расширения самого себя.

Проблема в том, что если я использую то же имя для сгенерированного кода, dlopen возвращаетдескриптор старого объекта, а не нового.

Код выглядит следующим образом: 

…generate code into test.cpp
system("gcc <args> test.cpp -o test.so");
void *handle = dlopen("test.so");
void *sym = dlsym(handle, "run");
(*sym)();
dlclose(handle);
…Do other work
…generate different code to test.cpp
system("gcc <args> test.cpp -o test.so");
void *handle = dlopen("test.so");
void *sym = dlsym(handle, "run");
(*sym)();
<crash here because the code isn't what was expected>

Является ли это основным недостатком в кэше кода dlopen или чем-то известным и не известнымхорошо документировано в dlopen?

1 Ответ

0 голосов
/ 20 мая 2018

Скорее всего dlclose не удалось выгрузить библиотеку.Обычно это происходит, когда он содержит символы GNU_UNIQUE (которые имеют тенденцию проникать, если вы связываетесь со статическим libstdc ++).Это можно проверить с помощью 

$ readelf -sW --dyn-syms path/to/libxyz.so | grep '\bUNIQUE\b'
...
3808: 0000000000302e78     8 OBJECT  UNIQUE DEFAULT   27 _ZNSt8messagesIcE2idE@@GLIBCXX_3.4

. Чтобы исправить это, вы можете попробовать одно из следующих действий:

  • построить библиотеку с -fvisibility=hidden и __attribute__((visibility("default"))), чтобы скрыть уникальные символы
  • сборка с -Wl,--version-script для достижения того же
  • сборка shlib с набором инструментов, который был настроен с --disable-gnu-unique-object (см. обсуждение в списке GCC )
...