Совместно используемые библиотеки C++ имеют повторяющиеся символы

I am noticing duplicate symbols present in .so file

Нравится?

$ cat foo.c
int foo(void)
{
    return 42;
}

Скомпилировать:

$ gcc -Wall -fPIC -c foo.c

Проверьте символы в объектном файле для foo:

$ readelf -s foo.o | grep foo
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS foo.c
     8: 0000000000000000    11 FUNC    GLOBAL DEFAULT    1 foo

Один удар.

Сделать общую библиотеку:

$ gcc -Wall -shared -o libfoo.so foo.o

Проверьте символы в общей библиотеке для foo:

$ readelf -s libfoo.so | grep foo
     5: 000000000000057a    11 FUNC    GLOBAL DEFAULT    9 foo
    29: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS foo.c
    44: 000000000000057a    11 FUNC    GLOBAL DEFAULT    9 foo

Теперь два удара.

Здесь нет ничего плохого. Смотрите еще часть картинки:

$ readelf -s foo.o | egrep '(foo|Symbol table|Ndx)' 
Symbol table '.symtab' contains 9 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS foo.c
     8: 0000000000000000    11 FUNC    GLOBAL DEFAULT    1 foo

Объектный файл имеет одну таблицу символов, его статическую таблицу символов .symtab, который используется компоновщиком для разрешения символов времени компоновки. Но:

$ readelf -s libfoo.so | egrep '(foo|Symbol table|Ndx)' 
Symbol table '.dynsym' contains 11 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     5: 000000000000057a    11 FUNC    GLOBAL DEFAULT    9 foo
Symbol table '.symtab' contains 48 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
    29: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS foo.c
    44: 000000000000057a    11 FUNC    GLOBAL DEFAULT    9 foo

в общей библиотеке есть таблицы символов два: статическая таблица символов .symtab, например объектный файл, а также динамическая таблица символов .dynsym, используемая загрузчиком для разрешения символов во время выполнения.

Когда вы связываете объектные файлы с общей библиотекой, компоновщик по умолчанию расшифровывает GLOBAL символы из их .symtabs в .symtabи.dynsym общего библиотеки, за исключением тех символов, которые имеют HIDDENвидимость в объектных файлах (который они получают от определения с помощью атрибут скрытой видимости при составлении).

Любые GLOBAL символы с HIDDEN видимостью в объектных файлах транскрибируются как LOCAL символы. с DEFAULT видимостью в .symtab общей библиотеки и не расшифровываются вообще в .dynsym общей библиотеки. Поэтому, когда общая библиотека связана с ничего другого, ни компоновщик, ни загрузчик не видят глобальные символы, которые были HIDDEN при компиляции.

Но кроме скрытых символов, которых зачастую нет, такие же глобальные символы появится в таблицах .symtab и .dynsym общей библиотеки. Каждый определенный символ которое появляется в обеих таблицах, относится к одному и тому же определению.

Позже комментарии ОП

I took the symbol table by running objdump -T command, which should ideally list symbols present only in dynamic symbol table.

Это приводит нас к другому объяснению, потому что objdump -T действительно сообщает только динамическая таблица символов (например, readelf --dyn-syms).

Обратите внимание, что символ сообщил дважды:

...
00aab4d0  w   DF .text  0000003c  Base        boost::asio::error::detail::misc_category::~misc_category()
...
00aab50c  w   DF .text  0000003c  Base        boost::asio::error::detail::misc_category::~misc_category()
...

классифицируется w в столбце 2 (как и все остальные символы в вашем фрагменте). Что objdump означает, что это что символ слабый.

Повторим наблюдение:

foo.hpp

#pragma once
#include <iostream>

struct foo
{
    explicit foo(int i)
    : _i{i}
    {
        std::cout << __PRETTY_FUNCTION__ << std::endl;
    }
    ~foo()
    {
        std::cout << __PRETTY_FUNCTION__ << std::endl;
    }
    int _i = 0;
};

бар.cpp

#include "foo.hpp"

foo bar()
{
    return foo(2);
}

жвачка.cpp

#include "foo.hpp"

foo gum()
{
    return foo(1);
}

Скомпилируйте и создайте разделяемую библиотеку:

$ g++ -Wall -Wextra -c -fPIC bar.cpp gum.cpp
$ g++ -shared -o libbargum.so bar.o gum.o

Посмотрите, какие символы динамичныйobjdump сообщает из struct foo:

$ objdump -CT libbargum.so | grep 'foo::'
00000000000009bc  w   DF .text  0000000000000046  Base        foo::foo(int)
00000000000009bc  w   DF .text  0000000000000046  Base        foo::foo(int)

Дублируйте слабые экспорты конструктора foo::foo(int). Так же, как то, что вы заметил.

Хотя держись за галочку. foo::foo(int) — это сигнатура метода C++, но не на самом деле это символ, который компоновщик может распознать. Давай сделаем это снова, на этот раз без разборки:

$ objdump -T libbargum.so | grep 'foo'
00000000000009bc  w   DF .text  0000000000000046  Base        _ZN3fooC1Ei
00000000000009bc  w   DF .text  0000000000000046  Base        _ZN3fooC2Ei

Теперь мы видим символы, которые видит компоновщик, и дублирования больше не видно: _ZN3fooC1Ei != _ZN3fooC2Ei, хотя оба символа имеют одинаковый адрес и

$ c++filt _ZN3fooC1Ei
foo::foo(int)
$ c++filt _ZN3fooC2Ei
foo::foo(int)

они оба относятся к одному и тому же, foo::foo(int). На самом деле их 5 различные символы - _ZN3fooCНEi, для 1 <= Н <= 5 - которые превращаются в foo::foo(int). (И g++ на самом деле использует _ZN3fooC1Ei, _ZN3fooC2Ei и _ZN3fooC5Ei в объекте файлы bar.o и gum.o).

Так что на самом деле в таблице динамических символов нет повторяющихся символов: подлый характер преобразования имен "многие к одному" просто заставляет его выглядеть именно так.

Но почему?

Боюсь, ответ на этот вопрос слишком длинный и сложный для этого.

Управляющее резюме

Компилятор GCC C++ использует два слабых символа, которые demangle одинаково ссылаться на глобальный встроенный метод класса по-разному, как часть его базовая формула для обеспечения успешного связывания глобальных встроенных методов классов в независимом от позиции коде. Это существенная проблема для любого компилятора, и формула GCC для нее не является единственно возможной. Clang имеет другой решение, которое предполагает использование синонимичных, но различных символов и поэтому не порождают иллюзорное «дублирование» символов, которые вы видели.