Path: utzoo!censor!geac!torsqnt!hybrid!scifi!bywater!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.internals
Subject: Re: finding out where the text/bss sits
Message-ID: <5214@auspex.auspex.com>
Date: 12 Jan 91 22:18:55 GMT
References: <1991Jan02.041209.9552@cs.widener.edu>
Organization: Auspex Systems, Santa Clara
Lines: 30

> 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).