From owner-freebsd-hackers Mon Feb 8 11:54:24 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA21471 for freebsd-hackers-outgoing; Mon, 8 Feb 1999 11:54:24 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA21466 for ; Mon, 8 Feb 1999 11:54:22 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id LAA18263; Mon, 8 Feb 1999 11:53:44 -0800 (PST) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id LAA16959; Mon, 8 Feb 1999 11:53:43 -0800 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id MAA06169; Mon, 8 Feb 1999 12:53:42 -0700 Message-ID: <36BF40C6.A2CA621D@softweyr.com> Date: Mon, 08 Feb 1999 12:53:42 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: John Polstra CC: Terry Lambert , hackers@FreeBSD.ORG Subject: Re: ldconfig and libraries References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Polstra wrote: > > Terry Lambert wrote: > > > I am saying that it shouldn't be read-only to a tool to manipulate > > the section contents. > > Of course it needn't be read-only to any tool. > > > In that regard, the location of the section should be after the > > executable code. > > It can be after the executable code, but it can't be after the > program's data. FreeBSD's kernel currently supports only 3 segments > for programs: text, data, and bss. They are laid out contiguously in > the address space, in that order. The only one that's read-only is > text, the first segment. So all read-only items have to be somewhere > in the text segment. They can be before or after the program code, > but that doesn't help. Because in either case, they'll still precede > the data segment. Thus changing the size of anything that's read-only > will force the data segment to move. That would require relocation, > which cannot be done for an executable. The relocation information > isn't present in the file any more. So make the field ALWAYS PATH_MAX (+1 ??) characters in length, and stick a zero-terminated string within that buffer. Changing the length of the string won't change the length of the field, and therefore won't require fixing up addresses in the data (or any other) segment. -- Where am I, and what am I doing in this handbasket? Wes Peters +1.801.915.2061 Softweyr LLC wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message