finding out where the text/bss sits

Rory Foster rlf at dptspd.sat.datapoint.com
Fri Jan 18 07:41:22 AEST 1991


Hmm.  What a polemic subject.

Let's see, I don't believe the checkaddr program will do the
trick.  Take the i386 kernel for example, each process has
a 4Gb address space (this is user virtual) and allows real
memory to be shared by each process.  Your user process is
stepping through its own virtual space, but it's a different
virtual space than the other processes on the system.

But let's say that you have a kernel that will let you step
through all real memory, there is a window where you process
could be swapped out by swtch and real memory is reorganized.
When swtch establishes your process again, the data is not
there.  Granted, that could be a small window.

OK, now the COFF issue.  Well, again these are virtual addresses.
You say, s_paddr is physical?  Sorry it's only "a cheap trick".
See Understanding and Using COFF by G. Gircys.  In the middle of
page 38, you'll read that s_vaddr and s_paddr are the same.
The COFF file is "relocatable", so enough said.

Now, if the question where asked, where will my own process
begin loading its sections into virtual memory, then COFF and
ELF should provide some help (depends if you want user virtual
or kernel virtual).  This, however, was not the question.

I believe the original question was to let ProcA read the bss
section of ProcB.  Yes, shared memory is probably what you
want.  Another approach is to write a system call, to locate
the data in real memory and copy it into the address space
of the appropriate process.  But why?  Shared memory is easier.

Regards,

Rory Foster
rlf at dptspd.sat.datapoint.com



More information about the Comp.unix.internals mailing list