From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: New dumping problem... Date: Wed, 30 Mar 2005 21:17:08 +0200 Message-ID: References: <4249AF87.6080206@swipnet.se> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1112211109 13100 80.91.229.2 (30 Mar 2005 19:31:49 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 30 Mar 2005 19:31:49 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 30 21:31:47 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DGitV-00023T-4d for ged-emacs-devel@m.gmane.org; Wed, 30 Mar 2005 21:30:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DGjA3-00062r-D0 for ged-emacs-devel@m.gmane.org; Wed, 30 Mar 2005 14:47:31 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DGj8W-0005WX-Ln for emacs-devel@gnu.org; Wed, 30 Mar 2005 14:45:56 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DGj8U-0005Vf-SN for emacs-devel@gnu.org; Wed, 30 Mar 2005 14:45:56 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DGj7r-00058S-EO for emacs-devel@gnu.org; Wed, 30 Mar 2005 14:45:15 -0500 Original-Received: from [195.54.107.70] (helo=mxfep01.bredband.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DGih2-00087f-6W; Wed, 30 Mar 2005 14:17:32 -0500 Original-Received: from coolsville.localdomain ([83.226.180.210] [83.226.180.210]) by mxfep01.bredband.com with ESMTP id <20050330191730.POJL25559.mxfep01.bredband.com@coolsville.localdomain>; Wed, 30 Mar 2005 21:17:30 +0200 In-Reply-To: Original-To: rms@gnu.org X-Mailer: Apple Mail (2.619.2) 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: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:35376 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:35376 > Indeed. The final solution must be to either fix unexec (ELF I > presume) > or move away from unexec to something else. > > When you say "fix unexec", what does that mean? > > Has anyone established that it is possible in principle > for unexec to do the right thing in this environment? > What change would be needed? > > Does anyone understand what the technical issue is? I haven't checked this specific problem, but the exec-shield problem was that there is a hole between data and bss. unexelf.c assumes these are next to each other. It should be possible to make two data sections, one for the original data and one for the original bss, that are mapped to two different addresses when dumping. But then sections in the dumped image needs to be expanded and that is tricky as all sections after needs to be moved as well. Jan D.