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: Mon, 11 Oct 2004 12:30:26 +0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <416A60C2.50408@swipnet.se> References: <20041004212031.GB2219@fencepost> <01c4ab96$Blat.v2.2.2$19340460@zahav.net.il> <05038177-188D-11D9-821D-000D93505B76@swipnet.se> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1097491352 16058 80.91.229.6 (11 Oct 2004 10:42:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 11 Oct 2004 10:42:32 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 11 12:42:22 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 1CGxdG-0001Fl-00 for ; Mon, 11 Oct 2004 12:42:22 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CGxia-0004qq-2J for ged-emacs-devel@m.gmane.org; Mon, 11 Oct 2004 06:47:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CGxZU-0004uf-FU for emacs-devel@gnu.org; Mon, 11 Oct 2004 06:38:28 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CGxZS-0004sZ-Cs for emacs-devel@gnu.org; Mon, 11 Oct 2004 06:38:26 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CGxZR-0004re-Qe for emacs-devel@gnu.org; Mon, 11 Oct 2004 06:38:26 -0400 Original-Received: from [195.54.107.70] (helo=mxfep01.bredband.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CGxSI-0007UJ-NB; Mon, 11 Oct 2004 06:31:03 -0400 Original-Received: from coolsville.localdomain ([213.115.28.241] [213.115.28.241]) by mxfep01.bredband.com with ESMTP id <20041011103057.PWFC3239.mxfep01.bredband.com@coolsville.localdomain>; Mon, 11 Oct 2004 12:30:57 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040916 X-Accept-Language: en-us, en Original-To: rms@gnu.org In-Reply-To: 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:28225 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:28225 Richard Stallman wrote > Currently we run temacs like this > % setarch i386 ./temacs ... > > What about running temacs this way whenever setarch exists? > If the makefile checks for the existence of setarch just before > it runs temacs, or tries first to run it using setarch and then > tries without setarch as a fallback, that would also do the job. > After all, running temacs has to be done on the actual target > platform, and then setarch ought to be available if it is needed. Yes, it would work to first run with setarch and then normally as a fallback. > 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. 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. I think this is the best, because then temacs can output some message that directs the user to etc/PROBLEMS if the heap address is still off at the second run. Jan D.