finding out where the text/bss sits

[Mike Stefanik/78125]

In article <1991Jan02.041209.9552 at cs.widener.edu>, brendan at cs.widener.edu (Brendan Kehoe) writes:
> 
>   Hi there .. this is relative to a program I've been hacking on. This
> is all on a Sun Sparc-1 under SunOS 4.1. First, I'm trying to find out
> the address of where a user's text, data, & bss segments are sitting
> (well, more so the bss than anything). I've been digging for hours &
> have come up with a few stringy clues, but nothing's come of it yet.
> 
>   What I want to be able to do is read in a structure, say
> 	struct blah {
> 		char *this;
> 		struct blah *that;
> 		struct blah *the_other;
> 	};
> from the bss of another process (it'd have been declared globally).
> And I can't assume that a namelist is in the executable. My two
> biggest problems are trying to find out where they're sitting and how
> to find out the position of the structure if it doesn't have a symbol
> table. (Is this impossible to work around?)
> 

[Mounting High Horse]

Unless I am reading this wrong, you are asking about one user process modifying
another user process' bss?  This is extremely bad karma!  For one thing, if
your machine (I know nothing about SPARC machines) even *allows* you to go
writing to arbitrary memory locations without generating exceptions, then I
would throw it in the dumper.

Let's say that process A wants to write to process B's memory: how could you
guarantee that process B's bss is even *in physical memory* at the time?
You can't.  This is what SHARED MEMORY is for.

BTW: The fact that you have globally declared structures *DOES NOT* mean that
they are global for every Tom, Dick, and Harry process on the machine -- it
means that it is global in the context of the current (ie: declaring) process.

To reiterate: USE SHARED MEMORY.  'Nuff said.

[Unmounting High Horse]
-----------------------------------------------------------------------------
Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation
UUCP: ...!uunet!bria!mike
"If it was hard to code, it should be harder to use!"