finding out where the text/bss sits

[josef Moellers]

In <304 at bria.AIX> mike at bria.AIX (Mike Stefanik/78125) writes:

>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]

Ever heard of /proc?

To answer the original question:
The header of an executable file contains the sizes of text, data and
bss of a program.

If Your system has a.out object file format, You need to find out
certain things about Your OS:
- where does it place the code? (I'm writing this on a MIPS and they put
  the code at soemthing like 0x400000, give or take a 0)
- what alignment is used? In order to efficiently implement protection
  and code-sharing, there are holes between text and data (and probably
  between data and bss)
>From these and from the sizes of the segments, You should be able to
compute the start address of bss.

If You have a system using coff, then this information should be
contained in the section headers:
	struct scnhdr {
		char	s_name[SYMNMLEN];	/* section name */
		long	s_paddr;		/* physical address */
		long	s_vaddr;		/* virtual address */
		:
	};

Then try to find the needle in the haystack B-{)

--
| Josef Moellers		| c/o Siemens Nixdorf Informationssysteme AG |
|  USA: mollers.pad at nixdorf.com	| Abt. STO-XS 113			     |
| !USA: mollers.pad at nixdorf.de	| Heinz-Nixdorf-Ring			     |
| Phone: (+49) 5251 104662	| D-4790 Paderborn			     |