From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Samuel Bronson Newsgroups: gmane.emacs.bugs Subject: bug#9927: 24.0.90; unexec/unexmacosx fails with GCC 4.6.1 Date: Fri, 29 Jun 2012 13:03:49 -0400 Message-ID: References: <6A5F6D17-397A-48F7-87E9-D77C09B60EC6@Freenet.DE> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1340989492 25392 80.91.229.3 (29 Jun 2012 17:04:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 29 Jun 2012 17:04:52 +0000 (UTC) Cc: control@debbugs.gnu.org To: 9927@debbugs.gnu.org, 9927-submitter@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 29 19:04:51 2012 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 1Skecl-000432-9P for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 Jun 2012 19:04:51 +0200 Original-Received: from localhost ([::1]:41357 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Skecl-0006Qz-27 for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 Jun 2012 13:04:51 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51397) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Skech-0006Q0-3c for bug-gnu-emacs@gnu.org; Fri, 29 Jun 2012 13:04:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Skece-0004tn-Fe for bug-gnu-emacs@gnu.org; Fri, 29 Jun 2012 13:04:46 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56196) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Skece-0004tW-1Y for bug-gnu-emacs@gnu.org; Fri, 29 Jun 2012 13:04:44 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Skego-0001Ji-9R for bug-gnu-emacs@gnu.org; Fri, 29 Jun 2012 13:09:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: <6A5F6D17-397A-48F7-87E9-D77C09B60EC6@Freenet.DE> Resent-From: Samuel Bronson Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 29 Jun 2012 17:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9927 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9927-submit@debbugs.gnu.org id=B9927.13409896954997 (code B ref 9927); Fri, 29 Jun 2012 17:09:02 +0000 Original-Received: (at 9927) by debbugs.gnu.org; 29 Jun 2012 17:08:15 +0000 Original-Received: from localhost ([127.0.0.1]:37504 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Skeg2-0001IV-SL for submit@debbugs.gnu.org; Fri, 29 Jun 2012 13:08:15 -0400 Original-Received: from mail-qc0-f172.google.com ([209.85.216.172]:46377) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Skefz-0001II-SP; Fri, 29 Jun 2012 13:08:13 -0400 Original-Received: by qcac10 with SMTP id c10so905278qca.3 for ; Fri, 29 Jun 2012 10:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:cc:x-mailer; bh=nzgq+Dg5SIIR+GJvPLFmLORP61QW5grk+7cBizqtrb4=; b=tTuQaIkCD20hTt1YBYKTtghlfGNjsURIvBh03QZo4i33g2KTFQxad4CEnipOHneKcE WFd6T9NLLA/vuWvPdmKVSReAPa4JWLrtPPl85KWFuWXLiiMB2HftWuVs3bz0nrjy2rdU WsCz5gd6Ijukz4Dh0Zbbaww9lSmx3ZYNm0eb7BtnBMs3k4t8kiAbY0xjw5mCFRi0x94B HwjCz35TJ3SF1UEApP0KF9+IzA+MiWuG32KHExZo1L6Q8iXqGe2sXeptRtW3Z6AGT7Ae FF6fKUUlTRq/4CL8TTGHkyHucyKAw/QtiixKcO5+ASpp1ui8XtB+mbHjENB87XklD+vf 9xOg== Original-Received: by 10.229.137.141 with SMTP id w13mr1172733qct.102.1340989432761; Fri, 29 Jun 2012 10:03:52 -0700 (PDT) Original-Received: from [192.168.0.18] (207-172-123-137.c3-0.upd-ubr1.trpr-upd.pa.cable.rcn.com. [207.172.123.137]) by mx.google.com with ESMTPS id cz12sm11352275qab.5.2012.06.29.10.03.50 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 10:03:51 -0700 (PDT) X-Mailer: Apple Mail (2.936) 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 (newer, 2) 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:61416 Archived-At: found 9927 24.1.50 retitle 9927 24.1.90; unexec/unexmacosx doesn't grok new sections emitted by GCC 4.6+ thanks Peter Dyballa wrote: > Am 18.05.2012 um 00:54 schrieb Andreas Schwab: > > > temacs, not emacs (which didn't build). > > src/temacs: file format mach-o-i386 > src/temacs > architecture: i386, flags 0x00000012: > EXEC_P, HAS_SYMS > start address 0x00002650 > Mach-O header: > magic : feedface > cputype : 00000007 (i386) > cpusubtype: 00000003 > filetype : 00000002 (execute) > ncmds : 00000019 (25) > sizeofcmds: 00000a04 > flags : 01000085 (noundefs+dyldlink+twolevel+0x1000000) > reserved : 00000002 [Irrelevant segments scrubbed] > Load command segment: name: __DATA > vmaddr: 00000000001b1000 vmsize: 00000000001dc000 > fileoff: 00000000001b0000 filesize: 0000000000198000 endoff: > 0000000000348000 > nsects: 10 flags: 0 > Section: __program_vars __DATA (bfdname: __DATA.__program_vars) > addr: 00000000001b1000 size: 0000000000000014 offset: 00000000001b0000 > align: 2 nreloc: 0 reloff: 0000000000000000 > flags: 00000000 (type: regular attr: -) > reserved1: 0x0 reserved2: 0x0 reserved3: 0x0 > Section: __nl_symbol_ptr __DATA (bfdname: .non_lazy_symbol_ptr) > addr: 00000000001b1014 size: 0000000000000b14 offset: 00000000001b0014 > align: 2 nreloc: 0 reloff: 0000000000000000 > flags: 00000006 (type: non_lazy_symbol_pointers attr: -) > first indirect sym: 536 (709 entries) reserved2: 0x0 reserved3: 0x0 > Section: __la_symbol_ptr __DATA (bfdname: .lazy_symbol_ptr) > addr: 00000000001b1b28 size: 0000000000000860 offset: 00000000001b0b28 > align: 2 nreloc: 0 reloff: 0000000000000000 > flags: 00000007 (type: lazy_symbol_pointers attr: -) > first indirect sym: 1245 (536 entries) reserved2: 0x0 reserved3: 0x0 > Section: __data __DATA (bfdname: .data) > addr: 00000000001b2390 size: 00000000001956dc offset: 00000000001b1390 > align: 4 nreloc: 0 reloff: 0000000000000000 > flags: 00000000 (type: regular attr: -) > reserved1: 0x0 reserved2: 0x0 reserved3: 0x0 > Section: __const __DATA (bfdname: .const_data) > addr: 0000000000347a70 size: 0000000000001008 offset: 0000000000346a70 > align: 4 nreloc: 0 reloff: 0000000000000000 > flags: 00000000 (type: regular attr: -) > reserved1: 0x0 reserved2: 0x0 reserved3: 0x0 We obviously know how to deal with all of the preceding sections... > Section: __static_data __DATA (bfdname: __DATA.__static_data) > addr: 0000000000348a80 size: 0000000000000031 offset: 0000000000347a80 > align: 4 nreloc: 0 reloff: 0000000000000000 > flags: 00000000 (type: regular attr: -) > reserved1: 0x0 reserved2: 0x0 reserved3: 0x0 While unexmacosx.c doesn't yet know how to deal with __DATA.__static_data, it would be easy enough to add it: just dump from memory, like __DATA.__data. (Apple's own assembler even has a ".static_data" shorthand for switching this section, they just never got around to making the compiler actually use it.) The real trouble is with these sections: > Section: __bss4 __DATA (bfdname: __DATA.__bss4) > addr: 0000000000348ac0 size: 0000000000006554 offset: 0000000000000000 > align: 4 nreloc: 0 reloff: 0000000000000000 > flags: 00000001 (type: zerofill attr: -) > reserved1: 0x0 reserved2: 0x0 reserved3: 0x0 > Section: __bss2 __DATA (bfdname: __DATA.__bss2) > addr: 000000000034f014 size: 000000000002fb68 offset: 0000000000000000 > align: 2 nreloc: 0 reloff: 0000000000000000 > flags: 00000001 (type: zerofill attr: -) > reserved1: 0x0 reserved2: 0x0 reserved3: 0x0 > Section: __pu_bss2 __DATA (bfdname: __DATA.__pu_bss2) > addr: 000000000037eb7c size: 0000000000005414 offset: 0000000000000000 > align: 2 nreloc: 0 reloff: 0000000000000000 > flags: 00000001 (type: zerofill attr: -) > reserved1: 0x0 reserved2: 0x0 reserved3: 0x0 > Section: __pu_bss4 __DATA (bfdname: __DATA.__pu_bss4) > addr: 0000000000383f90 size: 00000000000085e4 offset: 0000000000000000 > align: 4 nreloc: 0 reloff: 0000000000000000 > flags: 00000001 (type: zerofill attr: -) > reserved1: 0x0 reserved2: 0x0 reserved3: 0x0 You see, recent versions of GCC generate more-or-less arbitrarily many BSS sections on Darwin (see the darwin_output_aligned_bss () function in gcc/config/darwin.c). This is a problem for us because of what we try to do with BSS sections: else if (strncmp (sectp->sectname, SECT_BSS, 16) == 0) { extern char *my_endbss_static; unsigned long my_size; sectp->flags = S_REGULAR; /* Clear uninitialized local variables in statically linked libraries. In particular, function pointers stored by libSystemStub.a, which is introduced in Mac OS X 10.4 for binary compatibility with respect to long double, are cleared so that they will be reinitialized when the dumped binary is executed on other versions of OS. */ my_size = (unsigned long)my_endbss_static - sectp->addr; if (!(sectp->addr <= (unsigned long)my_endbss_static && my_size <= sectp->size)) unexec_error ("my_endbss_static is not in section %.16s", sectp->sectname); if (!unexec_write (sectp->offset, (void *) sectp->addr, my_size)) unexec_error ("cannot write section %.16s", sectp- >sectname); if (!unexec_write_zero (sectp->offset + my_size, sectp->size - my_size)) unexec_error ("cannot write section %.16s", sectp- >sectname); if (!unexec_write (header_offset, sectp, sizeof (struct section))) unexec_error ("cannot write section %.16s's header", sectp->sectname); } To do this for these new BSS sections, we'd need to insert dummy markers into each of these sections. This would be manageable enough if it were only these four, but it isn't necessarily: there are two categories we care about (__bss, used for statics, and __pu_bss, used for globals; the other two are for zero-length objects), and these each get one section per object alignment. For example, take a gander at this: iMac:ppc user$ otool -arch ppc -l /sw/src/fink.build/gcc47-4.7.1-1000/ darwin_objdir/gcc/cc1plus | grep bss sectname __bss2 sectname __pu_bss2 sectname __bss3 sectname __pu_bss0 sectname __pu_bss3 sectname __bss1 sectname __bss12 sectname __bss0 Now, we could *still* add a bunch of dummy variables to deal with all alignments within some range, but this might end up wasting a lot of space for the higher alignments (in theory, I think it could be kept down to 4x the highest alignment), and would be quite ugly in any case. (Also, the numbers appear to be log2(alignment) in GCC 4.7 but just aligment in GCC 4.6.) Unfortunately, it seems that Apple's tools don't like zero-length sections/objects, so we can't use those for the markers (and for which reason they get their own sections). How zero- length objects (which on other platforms are allowed to share addresses with other objects) could be of any use in their own sections is beyond me... I suppose, though, that if we could be sure that we aren't linking in any static libraries with these *new* BSS sections which will have trouble because of Emacs' dumping them, we could just skip that part; then all we'd need to do is make sure that my_endbss_static refers to an address in __DATA.__bss, not __DATA.__bss1 or __DATA.bss2 like it would naturally end up at on GCC 4.6 or 4.7 (respectively). (And make unexmacosx.c dump these new BSS sections, of course.)