Hello sham_hcu,
> Is it the same physical address space of libc.so.1 used by prog1 or different?
That depends. Linkers and loaders basically have 3 kinds of memory chunks (segments): code, data and BSS.
Code is the binary executable part, data is pre-defined data and BSS is zeroed out memory areas.
prog1 might store data in non-stack memory locations (static or global vars), so the data segment is used. This shouldn't be interfering with prog2.
So a .so library should only share the read-only parts of the library (and the OS should lock the respective memory pages against writing -> security issue!), and have individual, non-shared data and BSS segments.
Of course, this is a bit over-simplifying: There's also read-only, non-executable segments, which are used for constant variables, for example. A read-only BSS is also allowed in theory by some memory models (e.g. ELF), but that's not too sensible.
Recommended reading: John R. Levine: "Linkers and Loaders"
Regards,
stefan73
Main Topics
Browse All Topics





by: evilrixPosted on 2008-03-11 at 05:41:43ID: 21095079
DSO's (Dynamic Shared Objects) are loaded into physical memory once and then reference counted from then on. When the reference count reaches zero it will be unloaded from memory. When a program uses a DSO it's mapped into the process space of the program. Each program will shared the same DSO. This is the same on Linux and Windows; however, how it is implemented is obviously OS specific.