Что происходит с глобальными и статическими переменными в общей библиотеке, когда она динамически связана?

Я пытаюсь понять, что происходит, когда модули с глобальными и статическими переменными динамически связаны с приложением. По модулю я имею в виду каждый проект в решении (я много работаю с визуальной студией!). Эти модули либо встроены в *.lib, либо *.dll, либо сами *.exe.

Я понимаю, что двоичный файл приложения содержит глобальные и статические данные всех отдельных единиц перевода (объектных файлов) в сегменте данных (и только сегмент чтения только если const).

Что происходит, когда это приложение использует модуль A с динамической связью времени загрузки? Я предполагаю, что в DLL есть раздел для его глобальных и статических данных. Загружает ли операционная система? Если да, то где они загружаются в?
И что происходит, когда приложение использует модуль B с динамической привязкой во время выполнения?
Если у меня есть два модуля в моем приложении, которые используют A и B, являются копиями A и B-глобалов, созданных, как указано ниже (если это разные процессы)?
У DLLs A и B доступ к глобальным приложениям приложений?

(Просьба также указать ваши причины)

Цитата из MSDN:

Переменные, объявленные как глобальные в файле исходного кода DLL, рассматриваются как глобальные переменные компилятором и компоновщиком, но каждый процесс, который загружает данную DLL, получает свою собственную копию этих глобальных переменных DLL. Область статических переменных ограничена блоком, в котором объявлены статические переменные. В результате каждый процесс имеет свой собственный экземпляр глобальных и статических переменных DLL по умолчанию.

и здесь:

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

Спасибо.

Ответ 1

Это довольно известная разница между Windows и Unix-подобными системами.

Независимо от того, что:

Каждый процесс имеет свое собственное адресное пространство, а это означает, что между процессами никогда не используется какая-либо память (если вы не используете некоторую межпроцессную библиотеку или расширения связи).
До сих пор применяется одно правило определения (ODR), что означает, что вы можете иметь только одно определение глобальной переменной, видимое во время ссылки (статическая или динамическая привязка).

Итак, ключевая проблема здесь - действительно видимость.

Во всех случаях глобальные переменные (или функции) static никогда не видны извне модуля (dll/so или executable). Стандарт С++ требует, чтобы у них была внутренняя связь, что означает, что они не видны за пределами единицы перевода (которая становится объектным файлом), в которой они определены. Итак, это решает эту проблему.

Там, где это усложняется, вы имеете extern глобальные переменные. Здесь Windows и Unix-подобные системы совершенно разные.

В случае Windows (.exe и .dll) глобальные переменные extern не являются частью экспортированных символов. Другими словами, разные модули никоим образом не знают глобальных переменных, определенных в других модулях. Это означает, что вы получите ошибки компоновщика, если попытаетесь, например, создать исполняемый файл, который должен использовать переменную extern, определенную в DLL, потому что это недопустимо. Вам необходимо предоставить объектный файл (или статическую библиотеку) с определением этой переменной extern и связать его статически с исполняемым и DLL, в результате получится две различные глобальные переменные (одна из которых принадлежит исполняемому файлу и принадлежит к DLL).

Чтобы фактически экспортировать глобальную переменную в Windows, вы должны использовать синтаксис, аналогичный синтаксису экспорта/импорта функции, то есть:

#ifdef COMPILING_THE_DLL
#define MY_DLL_EXPORT extern "C" __declspec(dllexport)
#else
#define MY_DLL_EXPORT extern "C" __declspec(dllimport)
#endif

MY_DLL_EXPORT int my_global;

Когда вы это делаете, глобальная переменная добавляется в список экспортированных символов и может быть связана как и все другие функции.

В случае Unix-подобных сред (например, Linux) динамические библиотеки, называемые "общими объектами" с расширением .so, экспортируют все extern глобальные переменные (или функции). В этом случае, если вы используете привязку времени загрузки в любом месте к общему объекту, глобальные переменные являются общими, то есть связаны друг с другом как единое целое. В принципе, Unix-подобные системы разработаны таким образом, что практически нет никакой разницы между связыванием со статической или динамической библиотекой. Опять же, ODR применяется по всем направлениям: глобальная переменная extern будет разделяться между модулями, что означает, что она должна иметь только одно определение для всех загруженных модулей.

Наконец, в обоих случаях для Windows или Unix-подобных систем вы можете выполнить временную привязку динамической библиотеки, то есть используя либо LoadLibrary()/GetProcAddress()/FreeLibrary(), либо dlopen()/dlsym()/dlclose(). В этом случае вам нужно вручную получить указатель на каждый из символов, которые вы хотите использовать, и который включает в себя глобальные переменные, которые вы хотите использовать. Для глобальных переменных вы можете использовать GetProcAddress() или dlsym() так же, как и для функций, при условии, что глобальные переменные являются частью списка экспортированных символов (по правилам предыдущих абзацев).

И, конечно, в качестве необходимой окончательной заметки: следует избегать глобальных переменных. И я считаю, что текст, который вы цитировали (о том, что "неясно" ), относится точно к различиям, специфичным для платформы, которые я только что объяснил (динамические библиотеки на самом деле не определены стандартом С++, это платформа, гораздо менее надежна/переносима).