[TriLUG] Shared libs

[Pete at Soper.US]

Hi Joe,
    You can see how memory is being used by doing a cat of the "maps" file
under /proc/<pid> for a process id shown by "ps" (need root if it wasn't
created by you). File /proc/<pid>/maps corresponds to the process, and for
multithreaded processes there will be multiple dirs under /proc/<pid>/task
where one matches <pid> and the others correspond to the state of the 2nd
through nth thread. This is with a 2.6 kernel and the way thread state is
exposed has changed over the years.  The "maps" file is automagic: it
appears empty but its "contents" are generated on the fly when referenced.
the proc(5) man page covers this stuff.

I think the distinguishing feature of a shared library is that the code
("text") is position independent: it's branches/routine calls are relative
to the current location rather than absolute . This way it supports dynamic
linkage into a range of logical addresses that may be different for every
process using the library. That enables sharing across processes, but
there's also the huge advantage of being able to dynamically link with a
"fixed" library when recreating the executable  (with non-sharable "static"
libraries) is no longer possible.  When the special compile switch from your
example is used, what it's mainly doing is forcing position independent
("pic") code generation.

In special circumstances the text of a shared library can be written, such
as with a debugger. It's a first class "Doh!" when a breakpoint is put in an
unwise place in shared code on a live multiuser system.  :-)

-Pete

On Thu, Nov 12, 2009 at 9:18 PM, Patrick Brewer <patwbrewer at yahoo.com>wrote:

> One more detail...
>
> To the best of my memory Unix systems also do a lazy copy.  Meaning that
> even data can be shared until something is written to it.  On the write the
> memory page will be copied and assigned to the app doing the write.
> Not sure if that is true of data segments in shared libs, but I don't see
> why it wouldn't be the case.
>
>
>
> --
> TriLUG mailing list        : http://www.trilug.org/mailman/listinfo/trilug
> TriLUG FAQ  : http://www.trilug.org/wiki/Frequently_Asked_Questions
>


On Fri, Nov 13, 2009 at 6:19 AM, Joseph Mack NA3T <jmack at wm7d.net> wrote:

> On Thu, 12 Nov 2009, Patrick Brewer wrote:
>
>  One more detail...
>>
>> To the best of my memory Unix systems also do a lazy copy. Meaning that
>> even data can be shared until something is written to it. On the write the
>> memory page will be copied and assigned to the app doing the write. Not sure
>> if that is true of data segments in shared libs, but I don't see why it
>> wouldn't be the case.
>>
>
> sounds reasonable. How would I know? Would I see the copy on write with a
> debugger?
>
> Joe
>
> --
> Joseph Mack NA3T EME(B,D), FM05lw North Carolina
> jmack (at) wm7d (dot) net - azimuthal equidistant map
> generator at http://www.wm7d.net/azproj.shtml
> Homepage http://www.austintek.com/ It's GNU/Linux!
>
> --
> TriLUG mailing list        : http://www.trilug.org/mailman/listinfo/trilug
> TriLUG FAQ  : http://www.trilug.org/wiki/Frequently_Asked_Questions
>