From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: `exec shield' test in configure too strict? Date: Wed, 20 Oct 2004 22:33:16 +0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <457CE2D6-22D7-11D9-BDB3-000D93505B76@swipnet.se> References: <20041004212031.GB2219@fencepost> <01c4ab96$Blat.v2.2.2$19340460@zahav.net.il> <05038177-188D-11D9-821D-000D93505B76@swipnet.se> <416A60C2.50408@swipnet.se> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1098304507 24053 80.91.229.6 (20 Oct 2004 20:35:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 20 Oct 2004 20:35:07 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 20 22:34:57 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CKNAf-0004YO-00 for ; Wed, 20 Oct 2004 22:34:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CKNI4-0001WB-B1 for ged-emacs-devel@m.gmane.org; Wed, 20 Oct 2004 16:42:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CKNHY-0001Ex-DP for emacs-devel@gnu.org; Wed, 20 Oct 2004 16:42:04 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CKNHV-0001DH-7o for emacs-devel@gnu.org; Wed, 20 Oct 2004 16:42:01 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CKNHU-0001CS-UT for emacs-devel@gnu.org; Wed, 20 Oct 2004 16:42:00 -0400 Original-Received: from [195.54.107.70] (helo=mxfep01.bredband.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CKN9C-0000oH-ET; Wed, 20 Oct 2004 16:33:26 -0400 Original-Received: from coolsville.localdomain ([83.226.180.220] [83.226.180.220]) by mxfep01.bredband.com with ESMTP id <20041020203325.EBOM18265.mxfep01.bredband.com@coolsville.localdomain>; Wed, 20 Oct 2004 22:33:25 +0200 In-Reply-To: Original-To: rms@gnu.org X-Mailer: Apple Mail (2.619) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:28670 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:28670 >> Another idea: can `main' contain code to move its heap address to the >> desired place, at startup? > > No, as the desired place is not a mapped memory region, you can > not write > there. > > How about mapping a memory region at the desired place, then > putting the heap address there? It could work, but sounds tricky, you would have to mmap exactly between BSS and the heap. It is possible that the kernel could reject such a request. I haven't tested it though. > But we could do as described by Camm Maguire, check if the heap > is not > at the correct place at temacs startup, and if it is not, call > personality(LINUX32) and exec() temacs again. > > That also seems like a good method, perhaps better. It would require > testing whether the symbols pertaining to personalites are developed, > but that is a test done by compilation, so it should be > unproblematical. I have checked in this method now. I actually have an unexelf.c that works with exec-shield on now, but I have only tested it on Fedora Core 2. It is probably too risky to check it in this close to a release. Jan D.