From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#13783: simplify data_start configuration for Emacs Date: Fri, 22 Feb 2013 15:05:35 +0200 Message-ID: <83d2vsmrc0.fsf@gnu.org> References: <512729DD.7040903@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1361538413 11977 80.91.229.3 (22 Feb 2013 13:06:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Feb 2013 13:06:53 +0000 (UTC) Cc: 13783@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Feb 22 14:07:15 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U8sLH-0005L4-HS for geb-bug-gnu-emacs@m.gmane.org; Fri, 22 Feb 2013 14:07:11 +0100 Original-Received: from localhost ([::1]:38620 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8sKw-0003yF-Vp for geb-bug-gnu-emacs@m.gmane.org; Fri, 22 Feb 2013 08:06:50 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:34964) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8sKp-0003f2-0D for bug-gnu-emacs@gnu.org; Fri, 22 Feb 2013 08:06:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U8sKm-0005aX-9q for bug-gnu-emacs@gnu.org; Fri, 22 Feb 2013 08:06:42 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38424) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8sKm-0005aT-6W for bug-gnu-emacs@gnu.org; Fri, 22 Feb 2013 08:06:40 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1U8sM5-0004G5-Vk for bug-gnu-emacs@gnu.org; Fri, 22 Feb 2013 08:08:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Feb 2013 13:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13783 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 13783-submit@debbugs.gnu.org id=B13783.136153844816307 (code B ref 13783); Fri, 22 Feb 2013 13:08:01 +0000 Original-Received: (at 13783) by debbugs.gnu.org; 22 Feb 2013 13:07:28 +0000 Original-Received: from localhost ([127.0.0.1]:43877 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U8sLX-0004Ex-6z for submit@debbugs.gnu.org; Fri, 22 Feb 2013 08:07:28 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:41091) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U8sLT-0004En-4E for 13783@debbugs.gnu.org; Fri, 22 Feb 2013 08:07:25 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MIM00C00HERMA00@a-mtaout20.012.net.il> for 13783@debbugs.gnu.org; Fri, 22 Feb 2013 15:05:16 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MIM00CETHOSM820@a-mtaout20.012.net.il>; Fri, 22 Feb 2013 15:05:16 +0200 (IST) In-reply-to: <512729DD.7040903@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:71643 Archived-At: > Date: Fri, 22 Feb 2013 00:18:37 -0800 > From: Paul Eggert > CC: Eli Zaretskii > > Attached is a proposed patch that follows on to the Bug#13650 > fixes, by simplifying the code to remove most of the > data_start stuff, which is obsolete. This affects the > Windows port so I'm CC:ing this to Eli. Could you please explain more about what this is intended to accomplish? Some things seem wrong (a few specific comments below), but I don't feel I understand this enough to suggest better/more correct ways to do what you want. E.g., are we removing the data-start thing on all platforms where GCPRO is a no-op, i.e. those which support USE_LSB_TAG? > === modified file 'src/unexcoff.c' > --- src/unexcoff.c 2013-01-02 16:13:04 +0000 > +++ src/unexcoff.c 2013-02-22 08:11:05 +0000 > @@ -99,7 +99,7 @@ > > #include > > -#include "mem-limits.h" > +extern unsigned char *get_data_start (void); > > static long block_copy_start; /* Old executable start point */ > static struct filehdr f_hdr; /* File header */ > @@ -168,7 +168,7 @@ > pagemask = getpagesize () - 1; > > /* Adjust text/data boundary. */ > - data_start = (int) start_of_data (); > + data_start = (int) get_data_start (); > data_start = ADDR_CORRECT (data_start); > data_start = data_start & ~pagemask; /* (Down) to page boundary. */ This part is wrong: unexcoff.c is used only by the MSDOS build, but get_data_start is defined in w32heap.c, which is for the MS-Windows build. I'm not sure how to DTRT here (see above); all I can say at this point is that the MSDOS build currently defines DATA_START, see msdos/sed2v2.inp, and that definition is then used in start_of_data. > +/* Start of data. It is OK if this is approximate; it's used only as > + a heuristic. */ > +extern char data_start[]; > +#ifndef HAVE_DATA_START > +/* Initialize to nonzero, so that it's put into data and not bss. > + Link this file's object code first, so that this symbol is near the > + start of data. */ > +char data_start[1] = { 1 }; > +#endif Should platforms that HAVE_DATA_START initialize data_start to some value? Should _all_ platforms do that? If not, which ones should? > #ifdef REL_ALLOC > - extern POINTER (*real_morecore) (ptrdiff_t); > + extern void *(*real_morecore) (ptrdiff_t); This needs corresponding changes in ralloc.c, I think, at least for consistency if nothing else. > - extern POINTER (*__morecore) (ptrdiff_t); > + extern void *(*__morecore) (ptrdiff_t); Likewise. Thanks.