2013-02-14 2 views
2

Я знаком с общей макетом памяти программы (например, текстовым сегментом, сегментом данных, кучей, стекю и т. Д.) И пытаюсь найти что-то похожее на описание и диаграммы здесь:Linking/build vernacular/jargon - Методы динамической компоновки

http://www.tenouk.com/Bufferoverflowc/Bufferoverflow1c.html

Однако я пытаюсь выяснить три различных случая, каждый из которых включал использование внешних библиотек:

  1. Статическое связывание внешней библиотеки во время сборки (т.е. libtest.a в ldflags)
  2. Динамическая связь внешней библиотеки во время сборки (т.е. libtest.so в ldflags)
  3. Динамическая связь внешней библиотеки во время выполнения (например: libtest.soНЕ в ldflags, но библиотека загружается через dlopen()/dlsym())

Может ли кто-нибудь более знакомый с этим объяснить расположение памяти для меня? Меня особенно интересует различие, если оно есть, между случаями (2) и (3).

спасибо.

+1

В случае (2) связь все еще происходит во время соединения, а не времени сборки. Стек (ы) и куча (и) кучи будут распределены для всех трех случаев. В случае (1) разделы текста и данных библиотеки будут объединены с разделами ваших объектных файлов. В случаях (2) и (3) каждая динамически связанная библиотека будет иметь свои собственные разделы текста и данных, которые могут быть перемещены загрузчиком во время выполнения. – jerry

+0

Спасибо. +1. Жаль, что это был не ответ. Голосование закрывается. – DevNull

ответ

1

Я нашел Руководство по компоновщикам Solaris (по адресу http://docs.oracle.com/cd/E26502_01/html/E26507/index.html), чтобы быть очень хорошо написанным и невероятно полезным при объяснении чрезвычайно сложной утилиты.

Диаграмма, вы можете найти их на http://docs.oracle.com/cd/E26502_01/html/E26507/chapter6-93046.html#scrolltoc, http://docs.oracle.com/cd/E26502_01/html/E26507/chapter6-34713.html#scrolltoc, чтобы быть полезным.

+0

Спасибо. Это очень полезно. – DevNull