Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!hsdndev!think.com!linus!nixbur!nixpbe!ugun13!ugum01!josef From: josef@nixpbe.nixdorf.de (josef Moellers) Newsgroups: comp.unix.internals Subject: Re: finding out where the text/bss sits Message-ID: Date: 7 Jan 91 08:51:05 GMT References: <1991Jan02.041209.9552@cs.widener.edu> <304@bria.AIX> Sender: news@ugun13.UUCP Lines: 75 In <304@bria.AIX> mike@bria.AIX (Mike Stefanik/78125) writes: >In article <1991Jan02.041209.9552@cs.widener.edu>, brendan@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@nixdorf.com | Abt. STO-XS 113 | | !USA: mollers.pad@nixdorf.de | Heinz-Nixdorf-Ring | | Phone: (+49) 5251 104662 | D-4790 Paderborn |