Xref: utzoo comp.mail.sendmail:3335 alt.sys.sun:4148
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!olivea!uunet!mcsun!hp4nl!fwi.uva.nl!casper
From: casper@fwi.uva.nl (Casper H.S. Dik)
Newsgroups: comp.mail.sendmail,alt.sys.sun
Subject: Re: sendmail frozen config and Sun shared libraries
Message-ID: <1991Jun5.111401.7008@fwi.uva.nl>
Date: 5 Jun 91 11:14:01 GMT
Article-I.D.: fwi.1991Jun5.111401.7008
References: <1991Jun4.173143.29157@watmath.waterloo.edu>
Sender: news@fwi.uva.nl
Organization: FWI, University of Amsterdam
Lines: 36
Nntp-Posting-Host: ophelia.fwi.uva.nl

gamiddle@watmath.waterloo.edu (Guy Middleton) writes:

>I just installed a new sendmail (5.65+IDA from DECWRL), and encountered the
>strangest bug.

[example deleted]

>All of this works fine on other systems, and on a Sun if I compile without
>shared libraries (using cc -Bstatic).  There is obviously some trick to
>saving the data segment of a dynamically-linked program (as is done by
>sendmail -bz).  Does anybody know what it is?

You can't reliably save the data segment of a dynamically linked
executable.

There are two reasons for this:

	o Parts of the data segment (the parts private to the library)
	  are mapped in memory at an unknown location.
	  (I don't know how a process can find all it's memory
	  mapped objects, except when digging in the kernel)
	
	o The first bit of the data segment contains the private information
	  of the runtime loader. One of the things stored here, the
	  procedure linkage table (plt), contains the addresses of the
	  resolved library functions. If you change the stack limit,
	  the library is mapped at a different location, and the addresses
	  filled in before the segment was dumped, are faulty.

If you want to dump the data segment (e.g. with undump or unexec), the
executable must be linked with -Bstatic

Casper
--
						|	Casper H.S. Dik
	RELIGION KILLS				|	casper@fwi.uva.nl