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