finding out where the text/bss sits
Guy Harris
guy at auspex.auspex.com
Sun Jan 13 09:18:55 AEST 1991
> Was that sufficiently obscure?
Yes, actually. The really obscure part, as others have noted, is how
you plan to have process A get any access to the BSS space of process B.
UNIX systems generally don't let that happen unless process A is
debugging process B, either by:
using "ptrace()" - which, on most UNIX systems, only lets a
parent debug a child, but in SunOS after some 3.x
release lets a process attach to another one *if* the UIDs of the
process permit that;
or
using "/proc" - no, it's not "/dev/proc", at least not on the
systems I know of; it's a file system type, not a device driver
- which isn't in current SunOS releases, although it is in some
AT&T research systems, some S5R3 systems (the 3B4000 one?), S5R4
(including the release Sun will have, I presume), and some other
systems. Files in "/proc" are normally owned by the effective
user ID of the process they represent, and have mode
"rw-------", so they impose restrictions similar to those of the
SunOS PTRACE_ATTACH "ptrace()" request.
If you want the process to share memory, you're probably better off
using shared memory - either S5 shared memory (available since SunOS
3.2, but it's an optional feature that may not be configured into your
kernel) or "mmap()" of a plain file (available since SunOS 4.0, also
available in S5R4 and some other UNIX systems, and should be available
in 4.4BSD and OSF/1).
More information about the Comp.unix.internals
mailing list