[parent not found: <handler.9927.B.132010738317348.ack@debbugs.gnu.org>]
* bug#9927: Acknowledgement (24.0.90; unexec/unexmacosx fails with GCC 4.6.1 on intel Mac OS X 10.6.8)
[not found] ` <handler.9927.B.132010738317348.ack@debbugs.gnu.org>
@ 2012-04-17 9:17 ` Peter Dyballa
0 siblings, 0 replies; 29+ messages in thread
From: Peter Dyballa @ 2012-04-17 9:17 UTC (permalink / raw)
To: 9927
This problem still exists. The Apple modified compilers GCC 4.0, GCC 4.2, and LLVM GCC 4.2 plus the unmodified compilers GCC 4.4.6 and GCC 4.5.3 all can build GNU Emacs 24.1.50, but unmodified GCC 4.6.3 still fails on PPC Leopard, Mac OS X 10.5.8.
It is similar to the situation on intel Snow Leopard, Mac OS X 10.6.8: GCC 4.6.3 cannot produce bootstrap-emacs. Here is a try for 32-bit executable and --with-wide-int:
--- Header Information ---
Magic = 0xfeedface
CPUType = 7
CPUSubType = 3
FileType = 0x2
NCmds = 27
SizeOfCmds = 2812
Flags = 0x01000085
Highest address of load commands in input file: 0x621000
Lowest offset of all sections in __TEXT segment: 0x1900
--- List of Load Commands in Input File ---
# cmd cmdsize name address size
0 LC_SEGMENT 56 __PAGEZERO 0 0x1000
1 LC_SEGMENT 600 __TEXT 0x1000 0x26e000
__text 0x2900 0x2018b6
__text_cold 0x2041b6 0x705
__text_startup 0x2048bb 0x1ab4
__symbol_stub 0x206370 0xe64
__stub_helper 0x2071d4 0x1808
__cstring 0x2089dc 0x159e2
__const 0x21e3c0 0xb40
__eh_frame 0x21ef00 0x500f4
2 LC_SEGMENT 872 __DATA 0x26f000 0x310000
__dyld 0x26f000 0x1c
__nl_symbol_ptr 0x26f01c 0x91c
__la_symbol_ptr 0x26f938 0x998
__data 0x2702d0 0x29f148
__const 0x50f420 0x1914
__static_data 0x510d40 0x31
__pu_bss3 0x510d78 0x858
__bss3 0x5115d0 0x1d08
__bss4 0x5132e0 0xca84
__pu_bss2 0x51fd64 0x7ac
__bss2 0x520510 0x5a9f8
__pu_bss4 0x57af10 0x3b14
3 LC_SEGMENT 56 __LINKEDIT 0x57f000 0xa2000
4 LC_DYLD_INFO_ONLY 48
5 LC_SYMTAB 24
6 LC_DYSYMTAB 80
7 LC_LOAD_DYLINKER 28
8 LC_UUID 24
9 LC_UNIXTHREAD 80
10 LC_LOAD_DYLIB 52
11 LC_LOAD_DYLIB 52
12 LC_LOAD_DYLIB 52
13 LC_LOAD_DYLIB 52
14 LC_LOAD_DYLIB 52
15 LC_LOAD_DYLIB 52
16 LC_LOAD_DYLIB 56
17 LC_LOAD_DYLIB 56
18 LC_LOAD_DYLIB 72
19 LC_LOAD_DYLIB 68
20 LC_LOAD_DYLIB 56
21 LC_LOAD_DYLIB 56
22 LC_LOAD_DYLIB 48
23 LC_LOAD_DYLIB 60
24 LC_LOAD_DYLIB 48
25 LC_LOAD_DYLIB 60
26 LC_LOAD_DYLIB 52
0x2bfc080 (sz: 0x3f1c/ 0x3f20)
0x2b00000 (sz: 0xfc080/ 0xfc080)
0x16fc080 (sz: 0x3f1d/ 0x3f20)
0x1600000 (sz: 0xfc07f/ 0xfc080)
0x2afc080 (sz: 0x3f1c/ 0x3f20)
0x2a00000 (sz: 0xfc080/ 0xfc080)
0x3ff8000 (sz: 0x452/ 0x7f98)
0x3800000 (sz: 0x4365e/0x7f8000)
0x27f8000 (sz: 0x7d7c/ 0x7f98)
0x2000000 (sz: 0x7f8000/0x7f8000)
0x1452000 (sz: 0/ 0x1000)
--- Load Commands written to Output File ---
Writing segment __PAGEZERO @ 0 ( 0/ 0x1000 @ 0)
Writing segment __TEXT @ 0 (0x26e000/0x26e000 @ 0x1000)
Writing segment __DATA @ 0x26e000 (0x310000/0x310000 @ 0x26f000)
section __dyld at 0x26e000 - 0x26e01c (sz: 0x1c)
section __nl_symbol_ptr at 0x26e01c - 0x26e938 (sz: 0x91c)
section __la_symbol_ptr at 0x26e938 - 0x26f2d0 (sz: 0x998)
section __data at 0x26f2d0 - 0x50e418 (sz: 0x29f148)
section __const at 0x50e420 - 0x50fd34 (sz: 0x1914)
unexec: unrecognized section name in __DATA segment
make[1]: *** [bootstrap-emacs] Error 1
make: *** [src] Error 2
--
Greetings
Pete
If you're not confused, you're not paying attention.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9927: 24.0.90; unexec/unexmacosx fails with GCC 4.6.1
2011-11-01 0:24 bug#9927: 24.0.90; unexec/unexmacosx fails with GCC 4.6.1 on intel Mac OS X 10.6.8 Peter Dyballa
[not found] ` <handler.9927.B.132010738317348.ack@debbugs.gnu.org>
@ 2012-06-29 17:03 ` Samuel Bronson
2012-06-29 19:19 ` Peter Dyballa
2012-06-30 16:47 ` Samuel Bronson
2014-08-09 17:05 ` bug#9927: 24.1.50; unexec/unexmacosx doesn't grok GCC 4.6+ sections Stefan Monnier
2014-09-17 18:39 ` Paul Eggert
3 siblings, 2 replies; 29+ messages in thread
From: Samuel Bronson @ 2012-06-29 17:03 UTC (permalink / raw)
To: 9927, 9927-submitter; +Cc: control
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 <Peter_Dyballa@Freenet.DE> 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.)
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#9927: 24.0.90; unexec/unexmacosx fails with GCC 4.6.1
2012-06-29 17:03 ` bug#9927: 24.0.90; unexec/unexmacosx fails with GCC 4.6.1 Samuel Bronson
@ 2012-06-29 19:19 ` Peter Dyballa
2012-06-30 16:47 ` Samuel Bronson
1 sibling, 0 replies; 29+ messages in thread
From: Peter Dyballa @ 2012-06-29 19:19 UTC (permalink / raw)
To: Samuel Bronson, 9927-quiet; +Cc: 9927-submitter, control, 9927
Am 29.06.2012 um 19:03 schrieb Samuel Bronson:
> 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.)
Apple itself states in http://developer.apple.com/library/mac/#qa/qa1118/_index.html that they "do not support statically linked binaries on Mac OS X." And from my experience it's really a bit complicated to build them. So your approach should be OK and work in the average case. And those few, if at all, who try to build static Emacsen on Mac OS X might need something else...
--
Greetings
Pete
Specifications are for the weak and timid!
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9927: 24.0.90; unexec/unexmacosx fails with GCC 4.6.1
2012-06-29 17:03 ` bug#9927: 24.0.90; unexec/unexmacosx fails with GCC 4.6.1 Samuel Bronson
2012-06-29 19:19 ` Peter Dyballa
@ 2012-06-30 16:47 ` Samuel Bronson
2013-07-25 19:37 ` Glenn Morris
1 sibling, 1 reply; 29+ messages in thread
From: Samuel Bronson @ 2012-06-30 16:47 UTC (permalink / raw)
To: 9927
Samuel Bronson <naesten@gmail.com> wrote:
> 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.)
Well, after my GCC 4.7 build finished, I had a go at building Emacs with
it and (after getting distracted for a bit playing with the
--enable-gcc-warnings flag) I got temacs to build and link. (There was
some awkwardness involving the -fobjc-exceptions flag that we'll need to
straighten out...)
I decided I might as well try the simplest thing that could possibly
work: just dump __DATA.__static_data in the usual way, and dump these
new BSS sections like __DATA.__bss, only in their entirety rather than
messing about with markers.
When my first try ended in SIGSEGV, I ran "gobjdump --all" on temacs and
didn't see any evidence of staticly-linked libraries besides libgcc and
gnulib; then I noticed that I hadn't looked closely enough at the code
I'd copied and pasted into my new "else if" clause and rewrote it to
ACTUALLY work like that for __DATA.__bss without the marker stuff, and
then I actually got an Emacs.app that worked!
You can see my changes at:
http://bazaar.launchpad.net/~naesten/emacs/nextstep-stuff/revision/108754
Be warned that the line numbers will probably be way off of emacs trunk
right now, since an earlier commit on my branch deletes largish swathes
of code that wasn't really doing anything useful.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9927: 24.0.90; unexec/unexmacosx fails with GCC 4.6.1
2012-06-30 16:47 ` Samuel Bronson
@ 2013-07-25 19:37 ` Glenn Morris
0 siblings, 0 replies; 29+ messages in thread
From: Glenn Morris @ 2013-07-25 19:37 UTC (permalink / raw)
To: Samuel Bronson; +Cc: 9927
Samuel Bronson wrote:
> I decided I might as well try the simplest thing that could possibly
> work: just dump __DATA.__static_data in the usual way, and dump these
> new BSS sections like __DATA.__bss, only in their entirety rather than
> messing about with markers.
>
> When my first try ended in SIGSEGV, I ran "gobjdump --all" on temacs and
> didn't see any evidence of staticly-linked libraries besides libgcc and
> gnulib; then I noticed that I hadn't looked closely enough at the code
> I'd copied and pasted into my new "else if" clause and rewrote it to
> ACTUALLY work like that for __DATA.__bss without the marker stuff, and
> then I actually got an Emacs.app that worked!
>
> You can see my changes at:
> http://bazaar.launchpad.net/~naesten/emacs/nextstep-stuff/revision/108754
Sorry for lack of response. If you have a patch that fixes this, could
you just send it here please? (The launchpad repo is hard to follow.)
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9927: 24.1.50; unexec/unexmacosx doesn't grok GCC 4.6+ sections
2011-11-01 0:24 bug#9927: 24.0.90; unexec/unexmacosx fails with GCC 4.6.1 on intel Mac OS X 10.6.8 Peter Dyballa
[not found] ` <handler.9927.B.132010738317348.ack@debbugs.gnu.org>
2012-06-29 17:03 ` bug#9927: 24.0.90; unexec/unexmacosx fails with GCC 4.6.1 Samuel Bronson
@ 2014-08-09 17:05 ` Stefan Monnier
2014-08-11 1:20 ` Glenn Morris
2014-08-11 1:40 ` Samuel Bronson
2014-09-17 18:39 ` Paul Eggert
3 siblings, 2 replies; 29+ messages in thread
From: Stefan Monnier @ 2014-08-09 17:05 UTC (permalink / raw)
To: 9927; +Cc: Samuel Bronson
Glenn Morris wrote:
> Samuel Bronson wrote:
> > You can see my changes at:
> > http://bazaar.launchpad.net/~naesten/emacs/nextstep-stuff/revision/108754
> Sorry for lack of response. If you have a patch that fixes this, could
> you just send it here please? (The launchpad repo is hard to follow.)
What the status on this. Has this been merged into trunk yet?
When I look at the above launchpad page, I see a commit that seems
completely unrelated.
Stefan
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#9927: 24.1.50; unexec/unexmacosx doesn't grok GCC 4.6+ sections
2014-08-09 17:05 ` bug#9927: 24.1.50; unexec/unexmacosx doesn't grok GCC 4.6+ sections Stefan Monnier
@ 2014-08-11 1:20 ` Glenn Morris
2014-08-11 1:40 ` Samuel Bronson
1 sibling, 0 replies; 29+ messages in thread
From: Glenn Morris @ 2014-08-11 1:20 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Samuel Bronson, 9927
Stefan Monnier wrote:
> Glenn Morris wrote:
>> Samuel Bronson wrote:
>> > You can see my changes at:
>> > http://bazaar.launchpad.net/~naesten/emacs/nextstep-stuff/revision/108754
>> Sorry for lack of response. If you have a patch that fixes this, could
>> you just send it here please? (The launchpad repo is hard to follow.)
>
> What the status on this. Has this been merged into trunk yet?
Nope, 'coz I don't know what "this" is to merge.
(IIUC, this is the reason the hydra OS X builds have been failing for ever.)
> When I look at the above launchpad page, I see a commit that seems
> completely unrelated.
Indeed.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9927: 24.1.50; unexec/unexmacosx doesn't grok GCC 4.6+ sections
2014-08-09 17:05 ` bug#9927: 24.1.50; unexec/unexmacosx doesn't grok GCC 4.6+ sections Stefan Monnier
2014-08-11 1:20 ` Glenn Morris
@ 2014-08-11 1:40 ` Samuel Bronson
2014-08-11 1:56 ` Glenn Morris
1 sibling, 1 reply; 29+ messages in thread
From: Samuel Bronson @ 2014-08-11 1:40 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9927
The status of this is that I got sidetracked trying to get bzr to do
the equivalent of "git rebase -i", and eventually I stopped messing
with the relevant Mac.
It looks like I did rebase at some point, not remembering that I'd
given a revision-number based link.
The changes are still available on the lp:~naesten/emacs/nexstep-stuff
branch, and I've now also imported the branch into git; you can see it
at http://anonscm.debian.org/cgit/users/naesten-guest/emacs.git/log/?h=nextstep-stuff
or get it using e.g. "git fetch
git://anonscm.debian.org/git/users/naesten-guest/emacs.git
nextstep-stuff".
(*Most* of the changes on that branch actually seem to be in unexmacosx.c.)
I have not, however, rebased the branch since it's abandonment; it's
still based on emacs-24.1-1709-g2faa523
I could attempt to rebase at least some of this (I don't expect it
will all rebase cleanly), but I'd have to find a place to set up the
iMac in order to do this properly.
On 8/9/14, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> Glenn Morris wrote:
>> Samuel Bronson wrote:
>> > You can see my changes at:
>> > http://bazaar.launchpad.net/~naesten/emacs/nextstep-stuff/revision/108754
>> Sorry for lack of response. If you have a patch that fixes this, could
>> you just send it here please? (The launchpad repo is hard to follow.)
>
> What the status on this. Has this been merged into trunk yet?
>
> When I look at the above launchpad page, I see a commit that seems
> completely unrelated.
>
>
> Stefan
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9927: 24.1.50; unexec/unexmacosx doesn't grok GCC 4.6+ sections
2014-08-11 1:40 ` Samuel Bronson
@ 2014-08-11 1:56 ` Glenn Morris
0 siblings, 0 replies; 29+ messages in thread
From: Glenn Morris @ 2014-08-11 1:56 UTC (permalink / raw)
To: Samuel Bronson; +Cc: 9927
Samuel Bronson wrote:
> (*Most* of the changes on that branch actually seem to be in unexmacosx.c.)
Yes, and IIRC from the last time I looked, most were stylistic/cosmetic,
so I gave up trying to find the minimum one that might fix this bug.
If you find it, please just send it as a patch, against whatever Emacs
version (obviously trunk would be preferable), and we'll try to figure
it out.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9927: 24.1.50; unexec/unexmacosx doesn't grok GCC 4.6+ sections
2011-11-01 0:24 bug#9927: 24.0.90; unexec/unexmacosx fails with GCC 4.6.1 on intel Mac OS X 10.6.8 Peter Dyballa
` (2 preceding siblings ...)
2014-08-09 17:05 ` bug#9927: 24.1.50; unexec/unexmacosx doesn't grok GCC 4.6+ sections Stefan Monnier
@ 2014-09-17 18:39 ` Paul Eggert
2014-09-17 19:48 ` Glenn Morris
` (2 more replies)
3 siblings, 3 replies; 29+ messages in thread
From: Paul Eggert @ 2014-09-17 18:39 UTC (permalink / raw)
To: 9927; +Cc: Peter Dyballa, Samuel Bronson
[-- Attachment #1: Type: text/plain, Size: 238 bytes --]
If I understand that branch correctly, the attached patch should suffice
to port to GCC 4.6+ on OS X. It's relative to trunk bzr 117895. I
don't have easy access to OS X to try it, though. Peter and/or Samuel,
does it work for you?
[-- Attachment #2: gcc4.6.patch --]
[-- Type: text/x-patch, Size: 2219 bytes --]
=== modified file 'src/ChangeLog'
--- src/ChangeLog 2014-09-17 18:27:36 +0000
+++ src/ChangeLog 2014-09-17 18:29:28 +0000
@@ -1,3 +1,7 @@
+2014-09-17 Samuel Bronson <naesten@gmail.com>
+
+ * unexmacosx.c (copy_data_segment): Port to GCC 4.6+ (Bug#9927).
+
2014-09-17 Paul Eggert <eggert@cs.ucla.edu>
Fix minor problems found by static checking.
=== modified file 'src/unexmacosx.c'
--- src/unexmacosx.c 2014-09-01 02:37:22 +0000
+++ src/unexmacosx.c 2014-09-17 18:28:19 +0000
@@ -879,6 +879,27 @@
if (!unexec_write (header_offset, sectp, sizeof (struct section)))
unexec_error ("cannot write section %.16s's header", sectp->sectname);
}
+ else if (strncmp (sectp->sectname, "__bss", 5) == 0
+ || strncmp (sectp->sectname, "__pu_bss", 8) == 0)
+ {
+ sectp->flags = S_REGULAR;
+
+ /* These sections are produced by GCC 4.6+.
+
+ FIXME: We possibly ought to clear uninitialized local
+ variables in statically linked libraries like for
+ SECT_BSS (__bss) above, but setting up the markers we
+ need in lastfile.c would be rather messy. See
+ darwin_output_aligned_bss () in gcc/config/darwin.c for
+ the root of the problem, keeping in mind that the
+ sections are numbered by their alignment in GCC 4.6, but
+ by log2(alignment) in GCC 4.7. */
+
+ if (!unexec_write (sectp->offset, (void *) sectp->addr, sectp->size))
+ unexec_error ("cannot copy section %.16s", sectp->sectname);
+ if (!unexec_write (header_offset, sectp, sizeof (struct section)))
+ unexec_error ("cannot write section %.16s's header", sectp->sectname);
+ }
else if (strncmp (sectp->sectname, "__la_symbol_ptr", 16) == 0
|| strncmp (sectp->sectname, "__nl_symbol_ptr", 16) == 0
|| strncmp (sectp->sectname, "__got", 16) == 0
@@ -890,6 +911,7 @@
|| strncmp (sectp->sectname, "__program_vars", 16) == 0
|| strncmp (sectp->sectname, "__mod_init_func", 16) == 0
|| strncmp (sectp->sectname, "__mod_term_func", 16) == 0
+ || strncmp (sectp->sectname, "__static_data", 16) == 0
|| strncmp (sectp->sectname, "__objc_", 7) == 0)
{
if (!unexec_copy (sectp->offset, old_file_offset, sectp->size))
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#9927: 24.1.50; unexec/unexmacosx doesn't grok GCC 4.6+ sections
2014-09-17 18:39 ` Paul Eggert
@ 2014-09-17 19:48 ` Glenn Morris
2014-09-17 19:59 ` Paul Eggert
2014-09-17 21:00 ` Peter Dyballa
2014-09-17 22:20 ` Peter Dyballa
2 siblings, 1 reply; 29+ messages in thread
From: Glenn Morris @ 2014-09-17 19:48 UTC (permalink / raw)
To: Paul Eggert; +Cc: Peter Dyballa, 9927, Samuel Bronson
Paul Eggert wrote:
> If I understand that branch correctly, the attached patch should
> suffice to port to GCC 4.6+ on OS X. It's relative to trunk bzr
> 117895. I don't have easy access to OS X to try it, though. Peter
> and/or Samuel, does it work for you?
You can always install it to trunk and see if the hydra os x build
starts working. :)
I think this is why it has been failing "for ever".
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9927: 24.1.50; unexec/unexmacosx doesn't grok GCC 4.6+ sections
2014-09-17 18:39 ` Paul Eggert
2014-09-17 19:48 ` Glenn Morris
@ 2014-09-17 21:00 ` Peter Dyballa
2014-09-17 21:10 ` Paul Eggert
2014-09-17 22:20 ` Peter Dyballa
2 siblings, 1 reply; 29+ messages in thread
From: Peter Dyballa @ 2014-09-17 21:00 UTC (permalink / raw)
To: Paul Eggert; +Cc: 9927
Am 17.09.2014 um 20:39 schrieb Paul Eggert:
> If I understand that branch correctly, the attached patch should suffice to port to GCC 4.6+ on OS X. It's relative to trunk bzr 117895. I don't have easy access to OS X to try it, though. Peter and/or Samuel, does it work for you?
>
> <gcc4.6.patch>
I decided to make it simple for me and applied your patch to the sources of emacs-24.3.93 – and it works with GCC 4.6.4! See here:
Pure-hashed: 23728 strings, 3453 vectors, 37104 conses, 3245 bytecodes, 82 others
Dumping under the name emacs
--- List of All Regions ---
address size prot maxp
0 0x1000 none none
0x1000 0x258000 r x rwx
0x259000 0x23f000 rw rwx
0x498000 0x5f000 rw rwx
0x4f7000 0xb9000 r rwx
0x5b0000 0x60000 r x rwx
0x610000 0x3000 rw rwx
0x613000 0x16000 r rwx
0x629000 0x32000 r x rwx
0x65b000 0x1000 rw rwx
0x65c000 0xc000 r rwx
0x668000 0x29000 r x rwx
0x691000 0x1000 rw rwx
0x692000 0xe000 r rwx
0x6a0000 0x6000 r x rwx
0x6a6000 0x1000 rw rwx
0x6a7000 0x3000 r rwx
0x6aa000 0xc000 r x rwx
0x6b6000 0x1000 rw rwx
0x6b7000 0x4000 r rwx
0x6bb000 0x3a000 r x rwx
0x6f5000 0x6000 rw rwx
0x6fb000 0x2000 r rwx
0x6fd000 0x1c000 r rwx
0x719000 0x10000 r x rwx
0x729000 0x1000 rw rwx
0x72a000 0x7000 r rwx
0x731000 0x3c000 r x rwx
0x76d000 0x3000 rw rwx
0x770000 0x1000 rw rwx
0x771000 0x11000 r rwx
0x782000 0x5000 r x rwx
0x787000 0x1000 rw rwx
0x788000 0x3000 r rwx
0x78b000 0x10000 r x rwx
0x79b000 0x1000 rw rwx
0x79c000 0x2000 rw rwx
0x79e000 0x5000 r rwx
0x7a3000 0xf5000 r x rwx
0x898000 0x3000 rw rwx
0x89b000 0x1e000 r rwx
0x8b9000 0x6000 r x rwx
0x8bf000 0x1000 rw rwx
0x8c0000 0x3000 r rwx
0x8c3000 0xe000 r x rwx
0x8d1000 0x1000 rw rwx
0x8d2000 0x7000 r rwx
0x8d9000 0x2a000 r x rwx
0x903000 0x1000 rw rwx
0x904000 0x1000 rw rwx
0x905000 0x10000 r rwx
0x915000 0x7e000 r x rwx
0x993000 0x4000 rw rwx
0x997000 0x2c000 r rwx
0x9c3000 0x2b000 r x rwx
0x9ee000 0x1000 rw rwx
0x9ef000 0xa000 r rwx
0x9f9000 0x12000 r x rwx
0xa0b000 0x1000 rw rwx
0xa0c000 0x6000 r rwx
0xa12000 0x30000 r x rwx
0xa42000 0x1000 rw rwx
0xa43000 0xe000 r rwx
0xa51000 0xb4000 r x rwx
0xb05000 0x1000 rw rwx
0xb06000 0x1e000 r rwx
0xb24000 0x5000 r x rwx
0xb29000 0x1000 rw rwx
0xb2a000 0x3000 r rwx
0xb2d000 0x1000 r x rwx
0xb2e000 0x1000 rw rwx
0xb2f000 0x2000 r rwx
0xb31000 0x110000 r x rwx
0xc41000 0x5000 rw rwx
0xc46000 0x1000 rw rwx
0xc47000 0x55000 r rwx
0xc9c000 0x35000 r x rwx
0xcd1000 0x3000 rw rwx
0xcd4000 0x8000 r rwx
0xcdc000 0x1a000 r x rwx
0xcf6000 0x2000 rw rwx
0xcf8000 0x1000 rw rwx
0xcf9000 0xd000 r rwx
0xd06000 0x12000 r x rwx
0xd18000 0x1000 rw rwx
0xd19000 0x3000 r rwx
0xd1c000 0x8000 r x rwx
0xd24000 0x1000 rw rwx
0xd25000 0x3000 r rwx
0xd28000 0x18000 r x rwx
0xd40000 0x1000 rw rwx
0xd41000 0x8000 rw rwx
0xd49000 0xa000 r rwx
0xd53000 0xc3000 r x rwx
0xe16000 0x5000 rw rwx
0xe1b000 0x1000 rw rwx
0xe1c000 0x4a000 r rwx
0xe66000 0x23000 r x rwx
0xe89000 0x1000 rw rwx
0xe8a000 0x3000 r rwx
0xe8d000 0x7000 r x rwx
0xe94000 0x3000 rw rwx
0xe97000 0x1000 r rwx
0xe98000 0x2000 r x rwx
0xe9a000 0x1000 rw rwx
0xe9b000 0x2000 r rwx
0xe9d000 0x3000 r x rwx
0xea0000 0x1000 rw rwx
0xea1000 0x3000 r rwx
0xea4000 0xa000 r x rwx
0xeae000 0x1000 rw rwx
0xeaf000 0x5000 r rwx
0xeb4000 0xfb000 r x rwx
0xfaf000 0x1000 rw rwx
0xfb0000 0x17000 r rwx
0xfc7000 0x1e000 r x rwx
0xfe5000 0x2000 rw rwx
0xfe7000 0x9000 r rwx
0xff0000 0xf000 r x rwx
0xfff000 0x1000 rw rwx
0x1000000 0x2000 r rwx
0x1002000 0x27000 r x rwx
0x1029000 0x2000 rw rwx
0x102b000 0x2000 rw rwx
0x102d000 0xf000 r rwx
0x103c000 0x2a000 r x rwx
0x1066000 0x2000 rw rwx
0x1068000 0x1c000 r rwx
0x1084000 0x2c000 r x rwx
0x10b0000 0x1000 rw rwx
0x10b1000 0xc000 r rwx
0x10bd000 0x9000 r x rwx
0x10c6000 0x1000 rw rwx
0x10c7000 0x6000 r rwx
0x10cd000 0x3f000 r x rwx
0x110c000 0x2000 rw rwx
0x110e000 0x10000 r rwx
0x111e000 0xc6000 r x rwx
0x11e4000 0x2000 rw rwx
0x11e6000 0x1000 rw rwx
0x11e7000 0x25000 r rwx
0x120c000 0x6c000 r x rwx
0x1278000 0x2000 rw rwx
0x127a000 0x2b000 r rwx
0x12a5000 0x2000 r x rwx
0x12a7000 0x1000 rw rwx
0x12a8000 0x1000 r rwx
0x12a9000 0x8000 r x rwx
0x12b1000 0x1000 rw rwx
0x12b2000 0x3000 r rwx
0x12b5000 0x6f000 r x rwx
0x1324000 0x4000 rw rwx
0x1328000 0x1f000 r rwx
0x1347000 0x22000 r x rwx
0x1369000 0x1000 rw rwx
0x136a000 0xd000 r rwx
0x1377000 0x2c000 r x rwx
0x13a3000 0x9000 rw rwx
0x13ac000 0x1000 rw rwx
0x13ad000 0x1d000 r rwx
0x13ca000 0x3000 r x rwx
0x13cd000 0x1000 rw rwx
0x13ce000 0x2000 r rwx
0x13d0000 0x16000 r x rwx
0x13e6000 0x1000 rw rwx
0x13e7000 0x11000 r rwx
0x13f8000 0x30000 r x rwx
--- List of Regions to be Dumped ---
address size prot maxp
0 0x1000 none none
0x1000 0x258000 r x rwx
0x259000 0x29e000 rw rwx
0x4f7000 0xb9000 r rwx
0x5b0000 0x60000 r x rwx
0x610000 0x3000 rw rwx
0x613000 0x16000 r rwx
0x629000 0x32000 r x rwx
0x65b000 0x1000 rw rwx
0x65c000 0xc000 r rwx
0x668000 0x29000 r x rwx
0x691000 0x1000 rw rwx
0x692000 0xe000 r rwx
0x6a0000 0x6000 r x rwx
0x6a6000 0x1000 rw rwx
0x6a7000 0x3000 r rwx
0x6aa000 0xc000 r x rwx
0x6b6000 0x1000 rw rwx
0x6b7000 0x4000 r rwx
0x6bb000 0x3a000 r x rwx
0x6f5000 0x6000 rw rwx
0x6fb000 0x1e000 r rwx
0x719000 0x10000 r x rwx
0x729000 0x1000 rw rwx
0x72a000 0x7000 r rwx
0x731000 0x3c000 r x rwx
0x76d000 0x4000 rw rwx
0x771000 0x11000 r rwx
0x782000 0x5000 r x rwx
0x787000 0x1000 rw rwx
0x788000 0x3000 r rwx
0x78b000 0x10000 r x rwx
0x79b000 0x3000 rw rwx
0x79e000 0x5000 r rwx
0x7a3000 0xf5000 r x rwx
0x898000 0x3000 rw rwx
0x89b000 0x1e000 r rwx
0x8b9000 0x6000 r x rwx
0x8bf000 0x1000 rw rwx
0x8c0000 0x3000 r rwx
0x8c3000 0xe000 r x rwx
0x8d1000 0x1000 rw rwx
0x8d2000 0x7000 r rwx
0x8d9000 0x2a000 r x rwx
0x903000 0x2000 rw rwx
0x905000 0x10000 r rwx
0x915000 0x7e000 r x rwx
0x993000 0x4000 rw rwx
0x997000 0x2c000 r rwx
0x9c3000 0x2b000 r x rwx
0x9ee000 0x1000 rw rwx
0x9ef000 0xa000 r rwx
0x9f9000 0x12000 r x rwx
0xa0b000 0x1000 rw rwx
0xa0c000 0x6000 r rwx
0xa12000 0x30000 r x rwx
0xa42000 0x1000 rw rwx
0xa43000 0xe000 r rwx
0xa51000 0xb4000 r x rwx
0xb05000 0x1000 rw rwx
0xb06000 0x1e000 r rwx
0xb24000 0x5000 r x rwx
0xb29000 0x1000 rw rwx
0xb2a000 0x3000 r rwx
0xb2d000 0x1000 r x rwx
0xb2e000 0x1000 rw rwx
0xb2f000 0x2000 r rwx
0xb31000 0x110000 r x rwx
0xc41000 0x6000 rw rwx
0xc47000 0x55000 r rwx
0xc9c000 0x35000 r x rwx
0xcd1000 0x3000 rw rwx
0xcd4000 0x8000 r rwx
0xcdc000 0x1a000 r x rwx
0xcf6000 0x3000 rw rwx
0xcf9000 0xd000 r rwx
0xd06000 0x12000 r x rwx
0xd18000 0x1000 rw rwx
0xd19000 0x3000 r rwx
0xd1c000 0x8000 r x rwx
0xd24000 0x1000 rw rwx
0xd25000 0x3000 r rwx
0xd28000 0x18000 r x rwx
0xd40000 0x9000 rw rwx
0xd49000 0xa000 r rwx
0xd53000 0xc3000 r x rwx
0xe16000 0x6000 rw rwx
0xe1c000 0x4a000 r rwx
0xe66000 0x23000 r x rwx
0xe89000 0x1000 rw rwx
0xe8a000 0x3000 r rwx
0xe8d000 0x7000 r x rwx
0xe94000 0x3000 rw rwx
0xe97000 0x1000 r rwx
0xe98000 0x2000 r x rwx
0xe9a000 0x1000 rw rwx
0xe9b000 0x2000 r rwx
0xe9d000 0x3000 r x rwx
0xea0000 0x1000 rw rwx
0xea1000 0x3000 r rwx
0xea4000 0xa000 r x rwx
0xeae000 0x1000 rw rwx
0xeaf000 0x5000 r rwx
0xeb4000 0xfb000 r x rwx
0xfaf000 0x1000 rw rwx
0xfb0000 0x17000 r rwx
0xfc7000 0x1e000 r x rwx
0xfe5000 0x2000 rw rwx
0xfe7000 0x9000 r rwx
0xff0000 0xf000 r x rwx
0xfff000 0x1000 rw rwx
0x1000000 0x2000 r rwx
0x1002000 0x27000 r x rwx
0x1029000 0x4000 rw rwx
0x102d000 0xf000 r rwx
0x103c000 0x2a000 r x rwx
0x1066000 0x2000 rw rwx
0x1068000 0x1c000 r rwx
0x1084000 0x2c000 r x rwx
0x10b0000 0x1000 rw rwx
0x10b1000 0xc000 r rwx
0x10bd000 0x9000 r x rwx
0x10c6000 0x1000 rw rwx
0x10c7000 0x6000 r rwx
0x10cd000 0x3f000 r x rwx
0x110c000 0x2000 rw rwx
0x110e000 0x10000 r rwx
0x111e000 0xc6000 r x rwx
0x11e4000 0x3000 rw rwx
0x11e7000 0x25000 r rwx
0x120c000 0x6c000 r x rwx
0x1278000 0x2000 rw rwx
0x127a000 0x2b000 r rwx
0x12a5000 0x2000 r x rwx
0x12a7000 0x1000 rw rwx
0x12a8000 0x1000 r rwx
0x12a9000 0x8000 r x rwx
0x12b1000 0x1000 rw rwx
0x12b2000 0x3000 r rwx
0x12b5000 0x6f000 r x rwx
0x1324000 0x4000 rw rwx
0x1328000 0x1f000 r rwx
0x1347000 0x22000 r x rwx
0x1369000 0x1000 rw rwx
0x136a000 0xd000 r rwx
0x1377000 0x2c000 r x rwx
0x13a3000 0xa000 rw rwx
0x13ad000 0x1d000 r rwx
0x13ca000 0x3000 r x rwx
0x13cd000 0x1000 rw rwx
0x13ce000 0x2000 r rwx
0x13d0000 0x16000 r x rwx
0x13e6000 0x1000 rw rwx
0x13e7000 0x11000 r rwx
0x13f8000 0x30000 r x rwx
--- Header Information ---
Magic = 0xfeedface
CPUType = 7
CPUSubType = 3
FileType = 0x2
NCmds = 43
SizeOfCmds = 3404
Flags = 0x01000085
Highest address of load commands in input file: 0x5b0000
Lowest offset of all sections in __TEXT segment: 0x1e90
--- List of Load Commands in Input File ---
# cmd cmdsize name address size
0 LC_SEGMENT 56 __PAGEZERO 0 0x1000
1 LC_SEGMENT 600 __TEXT 0x1000 0x258000
__text 0x2e90 0x1ea017
__text_startup 0x1ecea7 0x18ec
__text_cold 0x1ee793 0x3ea
__symbol_stub 0x1eeb7e 0x1080
__stub_helper 0x1efc00 0x1b8c
__cstring 0x1f178c 0x18503
__const 0x209c90 0xab0
__eh_frame 0x20a740 0x4e8bc
2 LC_SEGMENT 736 __DATA 0x259000 0x29e000
__dyld 0x259000 0x1c
__nl_symbol_ptr 0x25901c 0x8f0
__la_symbol_ptr 0x25990c 0xb00
__data 0x25a410 0x23ab30
__static_data 0x494f40 0x29
__const 0x494f6c 0x24e0
__pu_bss2 0x49744c 0x29dc
__bss3 0x499e28 0x4dd0
__bss2 0x49ebf8 0x56878
__pu_bss3 0x4f5470 0x1418
3 LC_SEGMENT 56 __LINKEDIT 0x4f7000 0xb9000
4 LC_DYLD_INFO_ONLY 48
5 LC_SYMTAB 24
6 LC_DYSYMTAB 80
7 LC_LOAD_DYLINKER 28
8 LC_UUID 24
9 unknown 16
10 LC_UNIXTHREAD 80
11 LC_LOAD_DYLIB 48
12 LC_LOAD_DYLIB 48
13 LC_LOAD_DYLIB 52
14 LC_LOAD_DYLIB 48
15 LC_LOAD_DYLIB 48
16 LC_LOAD_DYLIB 52
17 LC_LOAD_DYLIB 52
18 LC_LOAD_DYLIB 52
19 LC_LOAD_DYLIB 52
20 LC_LOAD_DYLIB 52
21 LC_LOAD_DYLIB 52
22 LC_LOAD_DYLIB 52
23 LC_LOAD_DYLIB 56
24 LC_LOAD_DYLIB 56
25 LC_LOAD_DYLIB 72
26 LC_LOAD_DYLIB 68
27 LC_LOAD_DYLIB 52
28 LC_LOAD_DYLIB 60
29 LC_LOAD_DYLIB 56
30 LC_LOAD_DYLIB 52
31 LC_LOAD_DYLIB 56
32 LC_LOAD_DYLIB 60
33 LC_LOAD_DYLIB 48
34 LC_LOAD_DYLIB 60
35 LC_LOAD_DYLIB 52
36 LC_LOAD_DYLIB 48
37 LC_LOAD_DYLIB 52
38 LC_LOAD_DYLIB 56
39 LC_LOAD_DYLIB 60
40 LC_LOAD_DYLIB 52
41 unknown 16
42 LC_DATA_IN_CODE 16
0x20fc080 (sz: 0x3f1c/ 0x3f20)
0x2000000 (sz: 0x2210f/ 0xfc080)
0x2ff8000 (sz: 0x5222/ 0x7f98)
0x2800000 (sz: 0x5207ff/0x7f8000)
0x155d000 (sz: 0/ 0x1000)
--- Load Commands written to Output File ---
Writing segment __PAGEZERO @ 0 ( 0/ 0x1000 @ 0)
Writing segment __TEXT @ 0 (0x258000/0x258000 @ 0x1000)
Writing segment __DATA @ 0x258000 (0x29e000/0x29e000 @ 0x259000)
section __dyld at 0x258000 - 0x25801c (sz: 0x1c)
section __nl_symbol_ptr at 0x25801c - 0x25890c (sz: 0x8f0)
section __la_symbol_ptr at 0x25890c - 0x25940c (sz: 0xb00)
section __data at 0x259410 - 0x493f40 (sz: 0x23ab30)
section __static_data at 0x493f40 - 0x493f69 (sz: 0x29)
section __const at 0x493f6c - 0x49644c (sz: 0x24e0)
section __pu_bss2 at 0x49644c - 0x498e28 (sz: 0x29dc)
section __bss3 at 0x498e28 - 0x49dbf8 (sz: 0x4dd0)
section __bss2 at 0x49dbf8 - 0x4f4470 (sz: 0x56878)
section __pu_bss3 at 0x4f4470 - 0x4f5888 (sz: 0x1418)
Writing segment __DATA @ 0x4f6000 ( 0/ 0x1000 @ 0x155d000)
Writing segment __DATA @ 0x4f6000 ( 0x2210f/ 0xfc000 @ 0x2000000)
Writing segment __DATA @ 0x519000 ( 0x3f9c/ 0x3fa0 @ 0x20fc000)
Writing segment __DATA @ 0x51d000 (0x5207ff/0x7f8000 @ 0x2800000)
Writing segment __DATA @ 0xa3e000 ( 0x5222/ 0x7f98 @ 0x2ff8000)
Writing segment __LINKEDIT @ 0xa44000 ( 0xb85bc/ 0xb9000 @ 0x4f7000)
Writing LC_DYLD_INFO_ONLY command
Writing LC_SYMTAB command
Writing LC_DYSYMTAB command
Writing LC_LOAD_DYLINKER command
Writing LC_UUID command
Writing unknown command
Writing LC_UNIXTHREAD command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing LC_LOAD_DYLIB command
Writing unknown command
Writing LC_DATA_IN_CODE command
4112 unused bytes follow Mach-O header
2209049 pure bytes used
Adding name emacs-24.3.93.1
I'll also try to build with GCC 4.7.3 and 4.8.2.
--
Greetings
Pete
One person with a belief is a social power equal to ninety-nine who have only interests.
– John Stuart Mill
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9927: 24.1.50; unexec/unexmacosx doesn't grok GCC 4.6+ sections
2014-09-17 21:00 ` Peter Dyballa
@ 2014-09-17 21:10 ` Paul Eggert
2014-09-18 2:37 ` Stefan Monnier
0 siblings, 1 reply; 29+ messages in thread
From: Paul Eggert @ 2014-09-17 21:10 UTC (permalink / raw)
To: Peter Dyballa; +Cc: 9927
Thanks for checking. This is not a regression, so it doesn't need to be
applied to the emacs-24 branch. However, perhaps we should do so
anyway, as the patch is localized to OS X, and not working with GCC
4.6.0 (dated 2011) or later is a reasonably big deal.
Stefan, what do you think?
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9927: 24.1.50; unexec/unexmacosx doesn't grok GCC 4.6+ sections
2014-09-17 21:10 ` Paul Eggert
@ 2014-09-18 2:37 ` Stefan Monnier
2014-09-18 5:27 ` Paul Eggert
0 siblings, 1 reply; 29+ messages in thread
From: Stefan Monnier @ 2014-09-18 2:37 UTC (permalink / raw)
To: Paul Eggert; +Cc: Peter Dyballa, 9927
> Thanks for checking. This is not a regression, so it doesn't need to be
> applied to the emacs-24 branch. However, perhaps we should do so anyway, as
> the patch is localized to OS X, and not working with GCC 4.6.0 (dated 2011)
> or later is a reasonably big deal.
> Stefan, what do you think?
Looking at the patch I have no idea how "safe" it is.
Stefan
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#9927: 24.1.50; unexec/unexmacosx doesn't grok GCC 4.6+ sections
2014-09-18 2:37 ` Stefan Monnier
@ 2014-09-18 5:27 ` Paul Eggert
2014-09-18 13:05 ` Stefan Monnier
` (2 more replies)
0 siblings, 3 replies; 29+ messages in thread
From: Paul Eggert @ 2014-09-18 5:27 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Peter Dyballa, 9927-done
Stefan Monnier wrote:
> Looking at the patch I have no idea how "safe" it is.
OK, thanks, I'll leave emacs-24 alone then. Closing the bug, as it
appears to be fixed in the trunk.
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#9927: 24.1.50; unexec/unexmacosx doesn't grok GCC 4.6+ sections
2014-09-18 5:27 ` Paul Eggert
@ 2014-09-18 13:05 ` Stefan Monnier
2014-10-04 9:02 ` Peter Dyballa
2014-10-06 16:16 ` Peter Dyballa
2 siblings, 0 replies; 29+ messages in thread
From: Stefan Monnier @ 2014-09-18 13:05 UTC (permalink / raw)
To: Paul Eggert; +Cc: Peter Dyballa, 9927-done
>> Looking at the patch I have no idea how "safe" it is.
> OK, thanks, I'll leave emacs-24 alone then. Closing the bug, as it appears
> to be fixed in the trunk.
I didn't mean to veto it, but rather that I can't judge whether it's OK
to include it.
Stefan
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#9927: 24.1.50; unexec/unexmacosx doesn't grok GCC 4.6+ sections
2014-09-18 5:27 ` Paul Eggert
2014-09-18 13:05 ` Stefan Monnier
@ 2014-10-04 9:02 ` Peter Dyballa
2014-10-04 17:19 ` Paul Eggert
2014-10-06 16:16 ` Peter Dyballa
2 siblings, 1 reply; 29+ messages in thread
From: Peter Dyballa @ 2014-10-04 9:02 UTC (permalink / raw)
To: Paul Eggert; +Cc: 9927-done
Am 18.09.2014 um 07:27 schrieb Paul Eggert:
> OK, thanks, I'll leave emacs-24 alone then. Closing the bug, as it appears to be fixed in the trunk.
I think it is not fixed trunk, because GNU Emacs pretest 24.3.94 does not have it. Trying to compile on PPC Mac OS X 10.5.8 (Leopard) with GCC 4.9.1 I got:
Loading .../emacs-24.3.94-mac-4.94/lisp/leim/leim-list.el (source)...
Finding pointers to doc strings...
Finding pointers to doc strings...done
Dumping under the name emacs
--- List of All Regions ---
address size prot maxp
0 0x1000 none none
0x1000 0x210000 r x rwx
0x211000 0x27f000 rw rwx
0x490000 0x62000 rw rwx
0x4f2000 0x2000 rw rwx
0x4f4000 0x9c000 r rwx
0x590000 0x30000 r x rwx
0x5c0000 0x1000 rw rwx
0x5c1000 0xa000 r rwx
0x5cb000 0x117000 r x rwx
0x6e2000 0x3000 rw rwx
0x6e5000 0x1000 rw rwx
0x6e6000 0x1000 rw rwx
0x6e7000 0x58000 r rwx
0x73f000 0x1a000 r x rwx
0x759000 0x1000 rw rwx
0x75a000 0x7000 r rwx
0x761000 0x3e000 r x rwx
0x79f000 0x1000 rw rwx
0x7a0000 0x10000 r rwx
0x7b0000 0x102000 r x rwx
0x8b2000 0x1000 rw rwx
0x8b3000 0x24000 r rwx
0x8d7000 0xa000 r x rwx
0x8e1000 0x1000 rw rwx
0x8e2000 0x2000 r rwx
0x8e4000 0xc9000 r x rwx
0x9ad000 0x2000 rw rwx
0x9af000 0x1000 rw rwx
0x9b0000 0x24000 r rwx
0x9d4000 0x11c000 r x rwx
0xaf0000 0x5000 rw rwx
0xaf5000 0x1000 rw rwx
0xaf6000 0x27000 r rwx
0xb1d000 0x40000 r x rwx
0xb5d000 0x3000 rw rwx
0xb60000 0xc000 r rwx
0xb6c000 0xcf000 r x rwx
0xc3b000 0x6000 rw rwx
0xc41000 0x1000 rw rwx
0xc42000 0x24000 r rwx
0xc66000 0x12000 r x rwx
0xc78000 0x1000 rw rwx
0xc79000 0x2000 r rwx
0xc7b000 0xb000 r x rwx
0xc86000 0x1000 rw rwx
0xc87000 0x2000 r rwx
0xc89000 0xc000 r x rwx
0xc95000 0x1000 rw rwx
0xc96000 0x5000 r rwx
0xc9b000 0x10000 r x rwx
0xcab000 0x1000 rw rwx
0xcac000 0x7000 r rwx
0xcb3000 0x3a000 r x rwx
0xced000 0x1000 rw rwx
0xcee000 0x1000 rw rwx
0xcef000 0xe000 r rwx
0xcfd000 0x31000 r x rwx
0xd2e000 0x1000 rw rwx
0xd2f000 0x8000 r rwx
0xd37000 0x79000 r x rwx
0xdb0000 0x4000 rw rwx
0xdb4000 0x10000 r rwx
0xdc4000 0x27000 r x rwx
0xdeb000 0x1000 rw rwx
0xdec000 0x6000 r rwx
0xdf2000 0x2c000 r x rwx
0xe1e000 0x2000 rw rwx
0xe20000 0xc000 r rwx
0xe2c000 0x1e000 r x rwx
0xe4a000 0x1000 rw rwx
0xe4b000 0x3000 r rwx
0xe4e000 0xfc000 r x rwx
0xf4a000 0x1000 rw rwx
0xf4b000 0xa000 r rwx
0xf55000 0x5000 r x rwx
0xf5a000 0x1000 rw rwx
0xf5b000 0x1000 r rwx
0xf5c000 0x3000 r x rwx
0xf5f000 0x1000 rw rwx
0xf60000 0x1000 r rwx
0xf61000 0x4000 r x rwx
0xf65000 0x1000 rw rwx
0xf66000 0x1000 r rwx
0xf67000 0x48000 r x rwx
0xfaf000 0x1000 rw rwx
0xfb0000 0x1b000 r rwx
0xfcb000 0x57000 r x rwx
0x1022000 0x3000 rw rwx
0x1025000 0xd000 r rwx
0x1032000 0x3000 r x rwx
0x1035000 0x1000 rw rwx
0x1036000 0x1000 r rwx
0x1037000 0x5000 r x rwx
0x103c000 0x1000 rw rwx
0x103d000 0x3000 r rwx
0x1040000 0x12000 r x rwx
0x1052000 0x1000 rw rwx
0x1053000 0xa000 r rwx
0x105d000 0x8000 r x rwx
0x1065000 0x1000 rw rwx
0x1066000 0x2000 r rwx
0x1068000 0xfc000 r x rwx
0x1164000 0x3000 rw rwx
0x1167000 0x1a000 r rwx
0x1181000 0xe000 r x rwx
0x118f000 0x1000 rw rwx
0x1190000 0x4000 r rwx
0x1194000 0x1f000 r x rwx
0x11b3000 0x2000 rw rwx
0x11b5000 0x4000 r rwx
0x11b9000 0xe000 r x rwx
0x11c7000 0x1000 rw rwx
0x11c8000 0x2000 r rwx
0x11ca000 0x2000 r x rwx
0x11cc000 0x1000 rw rwx
0x11cd000 0x1000 r rwx
0x11ce000 0x4000 r x rwx
0x11d2000 0x1000 rw rwx
0x11d3000 0x1000 r rwx
0x11d4000 0x16000 r x rwx
0x11ea000 0x1000 rw rwx
0x11eb000 0x6000 r rwx
0x11f1000 0x29000 r x rwx
0x121a000 0x5000 rw rwx
0x121f000 0x1c000 r rwx
0x123b000 0xd000 r x rwx
0x1248000 0x1000 rw rwx
0x1249000 0x2000 r rwx
0x124b000 0x2b000 r x rwx
0x1276000 0x1000 rw rwx
0x1277000 0x11000 r rwx
0x1288000 0x25000 r x rwx
0x12ad000 0x1000 rw rwx
0x12ae000 0xf000 r rwx
0x12bd000 0x5e000 r x rwx
0x131b000 0x1000 rw rwx
0x131c000 0x8000 r rwx
0x1324000 0x1000 none rwx
0x1325000 0x1000 rw rwx
0x1326000 0x1000 none rwx
0x1327000 0x2000 rw rwx
0x1329000 0x1000 r rw
0x132a000 0x1000 r rw
0x132b000 0xb000 rw rwx
0x1336000 0x1000 none rwx
0x1337000 0x1000 rw rwx
0x1338000 0x1000 none rwx
0x1339000 0x1e000 rw rwx
0x1357000 0x1e000 rw rwx
0x1375000 0x1e000 rw rwx
0x1393000 0x1e000 rw rwx
0x13b1000 0x1e000 rw rwx
0x13cf000 0x1e000 rw rwx
0x13ed000 0xf000 rw rwx
0x13fd000 0x1000 rw rwx
0x13fe000 0x1000 rw rwx
0x13ff000 0x1000 rw rwx
--- List of Regions to be Dumped ---
address size prot maxp
0 0x1000 none none
0x1000 0x210000 r x rwx
0x211000 0x2e3000 rw rwx
0x4f4000 0x9c000 r rwx
0x590000 0x30000 r x rwx
0x5c0000 0x1000 rw rwx
0x5c1000 0xa000 r rwx
0x5cb000 0x117000 r x rwx
0x6e2000 0x5000 rw rwx
0x6e7000 0x58000 r rwx
0x73f000 0x1a000 r x rwx
0x759000 0x1000 rw rwx
0x75a000 0x7000 r rwx
0x761000 0x3e000 r x rwx
0x79f000 0x1000 rw rwx
0x7a0000 0x10000 r rwx
0x7b0000 0x102000 r x rwx
0x8b2000 0x1000 rw rwx
0x8b3000 0x24000 r rwx
0x8d7000 0xa000 r x rwx
0x8e1000 0x1000 rw rwx
0x8e2000 0x2000 r rwx
0x8e4000 0xc9000 r x rwx
0x9ad000 0x3000 rw rwx
0x9b0000 0x24000 r rwx
0x9d4000 0x11c000 r x rwx
0xaf0000 0x6000 rw rwx
0xaf6000 0x27000 r rwx
0xb1d000 0x40000 r x rwx
0xb5d000 0x3000 rw rwx
0xb60000 0xc000 r rwx
0xb6c000 0xcf000 r x rwx
0xc3b000 0x7000 rw rwx
0xc42000 0x24000 r rwx
0xc66000 0x12000 r x rwx
0xc78000 0x1000 rw rwx
0xc79000 0x2000 r rwx
0xc7b000 0xb000 r x rwx
0xc86000 0x1000 rw rwx
0xc87000 0x2000 r rwx
0xc89000 0xc000 r x rwx
0xc95000 0x1000 rw rwx
0xc96000 0x5000 r rwx
0xc9b000 0x10000 r x rwx
0xcab000 0x1000 rw rwx
0xcac000 0x7000 r rwx
0xcb3000 0x3a000 r x rwx
0xced000 0x2000 rw rwx
0xcef000 0xe000 r rwx
0xcfd000 0x31000 r x rwx
0xd2e000 0x1000 rw rwx
0xd2f000 0x8000 r rwx
0xd37000 0x79000 r x rwx
0xdb0000 0x4000 rw rwx
0xdb4000 0x10000 r rwx
0xdc4000 0x27000 r x rwx
0xdeb000 0x1000 rw rwx
0xdec000 0x6000 r rwx
0xdf2000 0x2c000 r x rwx
0xe1e000 0x2000 rw rwx
0xe20000 0xc000 r rwx
0xe2c000 0x1e000 r x rwx
0xe4a000 0x1000 rw rwx
0xe4b000 0x3000 r rwx
0xe4e000 0xfc000 r x rwx
0xf4a000 0x1000 rw rwx
0xf4b000 0xa000 r rwx
0xf55000 0x5000 r x rwx
0xf5a000 0x1000 rw rwx
0xf5b000 0x1000 r rwx
0xf5c000 0x3000 r x rwx
0xf5f000 0x1000 rw rwx
0xf60000 0x1000 r rwx
0xf61000 0x4000 r x rwx
0xf65000 0x1000 rw rwx
0xf66000 0x1000 r rwx
0xf67000 0x48000 r x rwx
0xfaf000 0x1000 rw rwx
0xfb0000 0x1b000 r rwx
0xfcb000 0x57000 r x rwx
0x1022000 0x3000 rw rwx
0x1025000 0xd000 r rwx
0x1032000 0x3000 r x rwx
0x1035000 0x1000 rw rwx
0x1036000 0x1000 r rwx
0x1037000 0x5000 r x rwx
0x103c000 0x1000 rw rwx
0x103d000 0x3000 r rwx
0x1040000 0x12000 r x rwx
0x1052000 0x1000 rw rwx
0x1053000 0xa000 r rwx
0x105d000 0x8000 r x rwx
0x1065000 0x1000 rw rwx
0x1066000 0x2000 r rwx
0x1068000 0xfc000 r x rwx
0x1164000 0x3000 rw rwx
0x1167000 0x1a000 r rwx
0x1181000 0xe000 r x rwx
0x118f000 0x1000 rw rwx
0x1190000 0x4000 r rwx
0x1194000 0x1f000 r x rwx
0x11b3000 0x2000 rw rwx
0x11b5000 0x4000 r rwx
0x11b9000 0xe000 r x rwx
0x11c7000 0x1000 rw rwx
0x11c8000 0x2000 r rwx
0x11ca000 0x2000 r x rwx
0x11cc000 0x1000 rw rwx
0x11cd000 0x1000 r rwx
0x11ce000 0x4000 r x rwx
0x11d2000 0x1000 rw rwx
0x11d3000 0x1000 r rwx
0x11d4000 0x16000 r x rwx
0x11ea000 0x1000 rw rwx
0x11eb000 0x6000 r rwx
0x11f1000 0x29000 r x rwx
0x121a000 0x5000 rw rwx
0x121f000 0x1c000 r rwx
0x123b000 0xd000 r x rwx
0x1248000 0x1000 rw rwx
0x1249000 0x2000 r rwx
0x124b000 0x2b000 r x rwx
0x1276000 0x1000 rw rwx
0x1277000 0x11000 r rwx
0x1288000 0x25000 r x rwx
0x12ad000 0x1000 rw rwx
0x12ae000 0xf000 r rwx
0x12bd000 0x5e000 r x rwx
0x131b000 0x1000 rw rwx
0x131c000 0x8000 r rwx
0x1324000 0x1000 none rwx
0x1325000 0x1000 rw rwx
0x1326000 0x1000 none rwx
0x1327000 0x2000 rw rwx
0x1329000 0x2000 r rw
0x132b000 0xb000 rw rwx
0x1336000 0x1000 none rwx
0x1337000 0x1000 rw rwx
0x1338000 0x1000 none rwx
0x1339000 0xc3000 rw rwx
0x13fd000 0x3000 rw rwx
--- Header Information ---
Magic = 0xfeedface
CPUType = 18
CPUSubType = 10
FileType = 0x2
NCmds = 30
SizeOfCmds = 4212
Flags = 0x0000008d
Highest address of load commands in input file: 0x590000
Lowest offset of all sections in __TEXT segment: 0x29d4
--- List of Load Commands in Input File ---
# cmd cmdsize name address size
0 LC_SEGMENT 56 __PAGEZERO 0 0x1000
1 LC_SEGMENT 464 __TEXT 0x1000 0x210000
__text 0x39d4 0x1dc1f8
__symbol_stub1 0x1dfbcc 0x1c90
__cstring 0x1e185c 0x19982
__const 0x1fb1e0 0x12ab6
__text_cold 0x20dc98 0x1da8
__text_startup 0x20fa40 0x15c0
2 LC_SEGMENT 940 __DATA 0x211000 0x2e1000
__dyld 0x211000 0x1c
__nl_symbol_ptr 0x21101c 0x8ec
__la_symbol_ptr 0x211908 0x724
__const 0x21202c 0x2124
__cfstring 0x214150 0x510
__data 0x214660 0x27ac7c
__static_data 0x48f2dc 0xd
__bss2 0x48f2ec 0x59174
__bss3 0x4e8460 0x4c80
__pu_bss2 0x4ed0e0 0x1c40
__pu_bss3 0x4eed20 0x22d8
__bss1 0x4f0ff8 0xa
__bss0 0x4f1002 0x3e8
3 LC_SEGMENT 1008 __OBJC 0x4f2000 0x2000
__cat_cls_meth 0x4f2000 0x34
__cat_inst_meth 0x4f2034 0x9c
__message_refs 0x4f20d0 0x884
__cls_refs 0x4f2954 0x10c
__class 0x4f2a60 0x2d0
__meta_class 0x4f2d30 0x2d0
__cls_meth 0x4f3000 0x28
__inst_meth 0x4f3028 0x918
__protocol 0x4f3940 0x28
__category 0x4f3968 0x1c
__instance_vars 0x4f3984 0x33c
__module_info 0x4f3cc0 0x70
__symbols 0x4f3d30 0x7c
__image_info 0x4f3dac 0x8
4 LC_SEGMENT 56 __LINKEDIT 0x4f4000 0x9c000
5 LC_SYMTAB 24
6 LC_DYSYMTAB 80
7 LC_LOAD_DYLINKER 28
8 LC_UUID 24
9 LC_UNIXTHREAD 176
10 LC_LOAD_DYLIB 88
11 LC_LOAD_DYLIB 84
12 LC_LOAD_DYLIB 60
13 LC_LOAD_DYLIB 60
14 LC_LOAD_DYLIB 68
15 LC_LOAD_DYLIB 64
16 LC_LOAD_DYLIB 60
17 LC_LOAD_DYLIB 56
18 LC_LOAD_DYLIB 56
19 LC_LOAD_DYLIB 56
20 LC_LOAD_DYLIB 60
21 LC_LOAD_DYLIB 60
22 LC_LOAD_DYLIB 52
23 LC_LOAD_DYLIB 52
24 LC_LOAD_DYLIB 64
25 LC_LOAD_DYLIB 52
26 LC_LOAD_DYLIB 52
27 LC_LOAD_DYLIB 104
28 LC_LOAD_DYLIB 112
29 LC_LOAD_DYLIB 96
0x15fc080 (sz: 0x25bd/ 0x3f0a)
0x1500000 (sz: 0x31bd4/ 0xfc080)
0x27f8000 (sz: 0x681a/ 0x7f80)
0x2000000 (sz: 0x681800/0x7f8000)
0x17f2000 (sz: 0x3fff/ 0x5000)
0x13f2000 (sz: 0x3fff/ 0x5000)
0x17ed000 (sz: 0x3fff/ 0x5000)
0x13ed000 (sz: 0x3fff/ 0x5000)
0x13e8000 (sz: 0x3fff/ 0x5000)
0x13e3000 (sz: 0x3fff/ 0x5000)
0x13de000 (sz: 0x3fff/ 0x5000)
0x17d8000 (sz: 0x639e/ 0x7000)
0x13d9000 (sz: 0x3fff/ 0x5000)
0x13d4000 (sz: 0x3fff/ 0x5000)
0x17d1000 (sz: 0x6392/ 0x7000)
0x13cf000 (sz: 0x3fff/ 0x5000)
0x17cc000 (sz: 0x3fff/ 0x5000)
0x13ca000 (sz: 0x3fff/ 0x5000)
0x17c7000 (sz: 0x3fff/ 0x5000)
0x13c5000 (sz: 0x3fff/ 0x5000)
0x17c2000 (sz: 0x3fff/ 0x5000)
0x13c0000 (sz: 0x3fff/ 0x5000)
0x17bd000 (sz: 0x3fff/ 0x5000)
0x13bb000 (sz: 0x3fff/ 0x5000)
0x17b8000 (sz: 0x3fff/ 0x5000)
0x13b6000 (sz: 0x3fff/ 0x5000)
0x17b3000 (sz: 0x3fff/ 0x5000)
0x13b1000 (sz: 0x3fff/ 0x5000)
0x17ae000 (sz: 0x3fff/ 0x5000)
0x13ac000 (sz: 0x3fff/ 0x5000)
0x17a9000 (sz: 0x3fff/ 0x5000)
0x13a7000 (sz: 0x3fff/ 0x5000)
0x17a4000 (sz: 0x3fff/ 0x5000)
0x13a2000 (sz: 0x3fff/ 0x5000)
0x179f000 (sz: 0x3fff/ 0x5000)
0x139d000 (sz: 0x3fff/ 0x5000)
0x179a000 (sz: 0x3fff/ 0x5000)
0x1398000 (sz: 0x3fff/ 0x5000)
0x1795000 (sz: 0x3fff/ 0x5000)
0x1393000 (sz: 0x3fff/ 0x5000)
0x1790000 (sz: 0x3fff/ 0x5000)
0x138e000 (sz: 0x3fff/ 0x5000)
0x178b000 (sz: 0x3fff/ 0x5000)
0x1389000 (sz: 0x3fff/ 0x5000)
0x1786000 (sz: 0x3fff/ 0x5000)
0x1384000 (sz: 0x3fff/ 0x5000)
0x1781000 (sz: 0x3fff/ 0x5000)
0x137f000 (sz: 0x3fff/ 0x5000)
0x177c000 (sz: 0x3fff/ 0x5000)
0x137a000 (sz: 0x3fff/ 0x5000)
0x1777000 (sz: 0x3fff/ 0x5000)
0x1375000 (sz: 0x3fff/ 0x5000)
0x1772000 (sz: 0x3fff/ 0x5000)
0x1370000 (sz: 0x3fff/ 0x5000)
0x176d000 (sz: 0x3fff/ 0x5000)
0x136b000 (sz: 0x3fff/ 0x5000)
0x1768000 (sz: 0x3fff/ 0x5000)
0x1366000 (sz: 0x3fff/ 0x5000)
0x1763000 (sz: 0x3fff/ 0x5000)
0x1361000 (sz: 0x3fff/ 0x5000)
0x175e000 (sz: 0x3fff/ 0x5000)
0x135c000 (sz: 0x3fff/ 0x5000)
0x1759000 (sz: 0x3fff/ 0x5000)
0x1357000 (sz: 0x3fff/ 0x5000)
0x1754000 (sz: 0x3fff/ 0x5000)
0x1352000 (sz: 0x3fff/ 0x5000)
0x174f000 (sz: 0x3fff/ 0x5000)
0x134d000 (sz: 0x3fff/ 0x5000)
0x174a000 (sz: 0x3fff/ 0x5000)
0x1745000 (sz: 0x3fff/ 0x5000)
0x1740000 (sz: 0x3fff/ 0x5000)
0x173b000 (sz: 0x3fff/ 0x5000)
0x3727000 (sz: 0x3fff/ 0x5000)
0x1736000 (sz: 0x3fff/ 0x5000)
0x3722000 (sz: 0x3fff/ 0x5000)
0x1731000 (sz: 0x3fff/ 0x5000)
0x371d000 (sz: 0x3fff/ 0x5000)
0x172c000 (sz: 0x3fff/ 0x5000)
0x3718000 (sz: 0x3fff/ 0x5000)
0x1724000 (sz: 0x3fff/ 0x5000)
0x3713000 (sz: 0x3fff/ 0x5000)
0x171f000 (sz: 0x3fff/ 0x5000)
0x370e000 (sz: 0x3fff/ 0x5000)
0x3709000 (sz: 0x3fff/ 0x5000)
0x170c000 (sz: 0x3fff/ 0x5000)
0x16c3000 (sz: 0x3fff/ 0x5000)
0x16be000 (sz: 0x4548/ 0x5000)
0x16b9000 (sz: 0x3fff/ 0x5000)
0x16b4000 (sz: 0x3fff/ 0x5000)
0x16af000 (sz: 0x3fff/ 0x5000)
0x16aa000 (sz: 0x3fff/ 0x5000)
0x16a5000 (sz: 0x3fff/ 0x5000)
0x16a0000 (sz: 0x3fff/ 0x5000)
0x169b000 (sz: 0x3fff/ 0x5000)
0x1696000 (sz: 0x3fff/ 0x5000)
0x1691000 (sz: 0x3fff/ 0x5000)
0x168c000 (sz: 0x3fff/ 0x5000)
0x1687000 (sz: 0x3fff/ 0x5000)
0x1682000 (sz: 0x3fff/ 0x5000)
0x167d000 (sz: 0x3fff/ 0x5000)
0x1678000 (sz: 0x3fff/ 0x5000)
0x1673000 (sz: 0x3fff/ 0x5000)
0x166e000 (sz: 0x3fff/ 0x5000)
0x1669000 (sz: 0x3fff/ 0x5000)
0x1664000 (sz: 0x3fff/ 0x5000)
0x165f000 (sz: 0x3fff/ 0x5000)
0x165a000 (sz: 0x3fff/ 0x5000)
0x1655000 (sz: 0x3fff/ 0x5000)
0x1650000 (sz: 0x3fff/ 0x5000)
0x164b000 (sz: 0x3fff/ 0x5000)
0x1646000 (sz: 0x3fff/ 0x5000)
0x1641000 (sz: 0x3fff/ 0x5000)
0x163c000 (sz: 0x3fff/ 0x5000)
0x1637000 (sz: 0x3fff/ 0x5000)
0x1632000 (sz: 0x3fff/ 0x5000)
0x162d000 (sz: 0x3fff/ 0x5000)
0x1628000 (sz: 0x3fff/ 0x5000)
0x1623000 (sz: 0x3fff/ 0x5000)
0x161e000 (sz: 0x3fff/ 0x5000)
0x1619000 (sz: 0x3fff/ 0x5000)
0x1614000 (sz: 0x3fff/ 0x5000)
0x160f000 (sz: 0x3fff/ 0x5000)
0x160a000 (sz: 0x3fff/ 0x5000)
0x1605000 (sz: 0x3fff/ 0x5000)
0x1600000 (sz: 0x3fff/ 0x5000)
0x17f7000 (sz: 0x3fff/ 0x5000)
0x13f7000 (sz: 0x3fff/ 0x5000)
--- Load Commands written to Output File ---
Writing segment __PAGEZERO @ 0 ( 0/ 0x1000 @ 0)
Writing segment __TEXT @ 0 (0x210000/0x210000 @ 0x1000)
Writing segment __DATA @ 0x210000 (0x2e1000/0x2e1000 @ 0x211000)
section __dyld at 0x210000 - 0x21001c (sz: 0x1c)
section __nl_symbol_ptr at 0x21001c - 0x210908 (sz: 0x8ec)
section __la_symbol_ptr at 0x210908 - 0x21102c (sz: 0x724)
section __const at 0x21102c - 0x213150 (sz: 0x2124)
section __cfstring at 0x213150 - 0x213660 (sz: 0x510)
section __data at 0x213660 - 0x48e2dc (sz: 0x27ac7c)
unexec: unrecognized section __static_data in __DATA segment
make[1]: *** [bootstrap-emacs] Error 1
make: *** [src] Error 2
Cleaning and applying your patch for GCC 4.6, GNU Emacs built.
--
Greetings
Pete
A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.
- Douglas Adams, »Mostly Harmless«
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9927: 24.1.50; unexec/unexmacosx doesn't grok GCC 4.6+ sections
2014-10-04 9:02 ` Peter Dyballa
@ 2014-10-04 17:19 ` Paul Eggert
2014-10-04 18:18 ` Glenn Morris
2014-10-05 18:36 ` Peter Dyballa
0 siblings, 2 replies; 29+ messages in thread
From: Paul Eggert @ 2014-10-04 17:19 UTC (permalink / raw)
To: Peter Dyballa; +Cc: 9927-done
[-- Attachment #1: Type: text/plain, Size: 388 bytes --]
Peter Dyballa wrote:
> I think it is not fixed trunk, because GNU Emacs pretest 24.3.94 does not have it.
If I understand you correctly, you're saying that GNU Emacs 24.3.94 has the bug,
and that the bug went away when you applied the patch (attached), and that we
should therefore backport this patch to the emacs-24 branch. Is that what you
meant? If so, Stefan, OK if I do that?
[-- Attachment #2: osx.patch --]
[-- Type: text/plain, Size: 2219 bytes --]
=== modified file 'src/ChangeLog'
--- src/ChangeLog 2014-09-17 18:27:36 +0000
+++ src/ChangeLog 2014-09-17 19:58:31 +0000
@@ -1,3 +1,7 @@
+2014-09-17 Samuel Bronson <naesten@gmail.com>
+
+ * unexmacosx.c (copy_data_segment): Port to GCC 4.6+ (Bug#9927).
+
2014-09-17 Paul Eggert <eggert@cs.ucla.edu>
Fix minor problems found by static checking.
=== modified file 'src/unexmacosx.c'
--- src/unexmacosx.c 2014-09-01 02:37:22 +0000
+++ src/unexmacosx.c 2014-09-17 19:58:31 +0000
@@ -879,6 +879,27 @@
if (!unexec_write (header_offset, sectp, sizeof (struct section)))
unexec_error ("cannot write section %.16s's header", sectp->sectname);
}
+ else if (strncmp (sectp->sectname, "__bss", 5) == 0
+ || strncmp (sectp->sectname, "__pu_bss", 8) == 0)
+ {
+ sectp->flags = S_REGULAR;
+
+ /* These sections are produced by GCC 4.6+.
+
+ FIXME: We possibly ought to clear uninitialized local
+ variables in statically linked libraries like for
+ SECT_BSS (__bss) above, but setting up the markers we
+ need in lastfile.c would be rather messy. See
+ darwin_output_aligned_bss () in gcc/config/darwin.c for
+ the root of the problem, keeping in mind that the
+ sections are numbered by their alignment in GCC 4.6, but
+ by log2(alignment) in GCC 4.7. */
+
+ if (!unexec_write (sectp->offset, (void *) sectp->addr, sectp->size))
+ unexec_error ("cannot copy section %.16s", sectp->sectname);
+ if (!unexec_write (header_offset, sectp, sizeof (struct section)))
+ unexec_error ("cannot write section %.16s's header", sectp->sectname);
+ }
else if (strncmp (sectp->sectname, "__la_symbol_ptr", 16) == 0
|| strncmp (sectp->sectname, "__nl_symbol_ptr", 16) == 0
|| strncmp (sectp->sectname, "__got", 16) == 0
@@ -890,6 +911,7 @@
|| strncmp (sectp->sectname, "__program_vars", 16) == 0
|| strncmp (sectp->sectname, "__mod_init_func", 16) == 0
|| strncmp (sectp->sectname, "__mod_term_func", 16) == 0
+ || strncmp (sectp->sectname, "__static_data", 16) == 0
|| strncmp (sectp->sectname, "__objc_", 7) == 0)
{
if (!unexec_copy (sectp->offset, old_file_offset, sectp->size))
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#9927: 24.1.50; unexec/unexmacosx doesn't grok GCC 4.6+ sections
2014-10-04 17:19 ` Paul Eggert
@ 2014-10-04 18:18 ` Glenn Morris
2014-10-04 19:43 ` Paul Eggert
2014-10-05 18:36 ` Peter Dyballa
1 sibling, 1 reply; 29+ messages in thread
From: Glenn Morris @ 2014-10-04 18:18 UTC (permalink / raw)
To: Paul Eggert; +Cc: Peter Dyballa, 9927
Paul Eggert wrote:
> If I understand you correctly, you're saying that GNU Emacs 24.3.94
> has the bug, and that the bug went away when you applied the patch
> (attached), and that we should therefore backport this patch to the
> emacs-24 branch. Is that what you meant? If so, Stefan, OK if I do
> that?
We've been through this already.
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9927#119
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9927: 24.1.50; unexec/unexmacosx doesn't grok GCC 4.6+ sections
2014-10-04 17:19 ` Paul Eggert
2014-10-04 18:18 ` Glenn Morris
@ 2014-10-05 18:36 ` Peter Dyballa
2014-10-05 23:19 ` Paul Eggert
1 sibling, 1 reply; 29+ messages in thread
From: Peter Dyballa @ 2014-10-05 18:36 UTC (permalink / raw)
To: Paul Eggert; +Cc: 9927-done
Am 04.10.2014 um 19:19 schrieb Paul Eggert:
> If I understand you correctly, you're saying that GNU Emacs 24.3.94 has the bug, and that the bug went away when you applied the patch (attached), and that we should therefore backport this patch to the emacs-24 branch. Is that what you meant?
Exactly! I cannot check whether trunk, GNU Emacs 25.0.50, can be compiled because I get an error when I try to build with GCC 4.8.3 or any other C compiler, except GCC 4.0:
@(#)PROGRAM:ld PROJECT:ld64-136
configured to support archs: i386 x86_64 armv7 armv7s
Library search paths:
/opt/local/lib
/opt/local/lib
/opt/local/lib
/opt/local/lib
/opt/local/lib
/opt/local/lib
/opt/local/lib
/opt/local/lib
/opt/local/lib
/opt/local/lib
/opt/local/lib
/opt/local/lib
/opt/local/lib
/opt/local/lib
/opt/local/lib/gcc48/gcc/x86_64-apple-darwin10/4.8.3
/opt/local/lib/gcc48
/usr/lib
/usr/local/lib
Framework search paths:
/Library/Frameworks/
/System/Library/Frameworks/
duplicate symbol _Qleft in:
keyboard.o
buffer.o
duplicate symbol _Qright in:
keyboard.o
buffer.o
ld: 2 duplicate symbols for architecture x86_64
collect2: error: ld returned 1 exit status
make[2]: *** [temacs] Error 1
make[1]: *** [src] Error 2
make: *** [bootstrap] Error 2
--
Greetings
Pete
A lot of people mistake a short memory for a clear conscience.
– Doug Larson
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9927: 24.1.50; unexec/unexmacosx doesn't grok GCC 4.6+ sections
2014-10-05 18:36 ` Peter Dyballa
@ 2014-10-05 23:19 ` Paul Eggert
2014-10-06 1:29 ` Stefan Monnier
0 siblings, 1 reply; 29+ messages in thread
From: Paul Eggert @ 2014-10-05 23:19 UTC (permalink / raw)
To: Peter Dyballa; +Cc: 9927-done
Peter Dyballa wrote:
> I cannot check whether trunk, GNU Emacs 25.0.50, can be compiled because I get an error when I try to build
Thanks, I just now fixed that, in trunk bzr 118056.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9927: 24.1.50; unexec/unexmacosx doesn't grok GCC 4.6+ sections
2014-10-05 23:19 ` Paul Eggert
@ 2014-10-06 1:29 ` Stefan Monnier
2014-10-06 2:47 ` Paul Eggert
0 siblings, 1 reply; 29+ messages in thread
From: Stefan Monnier @ 2014-10-06 1:29 UTC (permalink / raw)
To: Paul Eggert; +Cc: Peter Dyballa, 9927-done
>> I cannot check whether trunk, GNU Emacs 25.0.50, can be compiled because
>> I get an error when I try to build
> Thanks, I just now fixed that, in trunk bzr 118056.
Did this bug affect 24.3 as well?
Stefan
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#9927: 24.1.50; unexec/unexmacosx doesn't grok GCC 4.6+ sections
2014-10-06 1:29 ` Stefan Monnier
@ 2014-10-06 2:47 ` Paul Eggert
2014-10-06 13:15 ` Stefan Monnier
0 siblings, 1 reply; 29+ messages in thread
From: Paul Eggert @ 2014-10-06 2:47 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Peter Dyballa, 9927-done
Stefan Monnier wrote:
>>> I cannot check whether trunk, GNU Emacs 25.0.50, can be compiled because
>>> I get an error when I try to build
>> Thanks, I just now fixed that, in trunk bzr 118056.
>
> Did this bug affect 24.3 as well?
The little bug that I fixed in trunk bzr 118056 was present only in the trunk;
it's never been in the emacs-24 branch. I think this little bug was introduced
in trunk bzr 117587 on 2014-07-27.
Bug#9927 itself affects 24.3 (and 23) as well. Apparently Emacs has been
unbuildable with GCC 4.6+ for quite some time on OS X. This bigger bug was
fixed in trunk bzr 117896, but that fix was apparently too late for the Emacs
24.4 cutoff.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9927: 24.1.50; unexec/unexmacosx doesn't grok GCC 4.6+ sections
2014-10-06 2:47 ` Paul Eggert
@ 2014-10-06 13:15 ` Stefan Monnier
0 siblings, 0 replies; 29+ messages in thread
From: Stefan Monnier @ 2014-10-06 13:15 UTC (permalink / raw)
To: Paul Eggert; +Cc: Peter Dyballa, 9927-done
>>>> I cannot check whether trunk, GNU Emacs 25.0.50, can be compiled because
>>>> I get an error when I try to build
>>> Thanks, I just now fixed that, in trunk bzr 118056.
>>
>> Did this bug affect 24.3 as well?
> The little bug that I fixed in trunk bzr 118056 was present only in the
> trunk; it's never been in the emacs-24 branch. I think this little bug was
> introduced in trunk bzr 117587 on 2014-07-27.
> Bug#9927 itself affects 24.3 (and 23) as well. Apparently Emacs has been
> unbuildable with GCC 4.6+ for quite some time on OS X. This bigger bug was
> fixed in trunk bzr 117896, but that fix was apparently too late for the
> Emacs 24.4 cutoff.
OK, good, thanks,
Stefan
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9927: 24.1.50; unexec/unexmacosx doesn't grok GCC 4.6+ sections
2014-09-18 5:27 ` Paul Eggert
2014-09-18 13:05 ` Stefan Monnier
2014-10-04 9:02 ` Peter Dyballa
@ 2014-10-06 16:16 ` Peter Dyballa
2 siblings, 0 replies; 29+ messages in thread
From: Peter Dyballa @ 2014-10-06 16:16 UTC (permalink / raw)
To: Paul Eggert; +Cc: 9927-done
Am 18.09.2014 um 07:27 schrieb Paul Eggert:
> Closing the bug, as it appears to be fixed in the trunk.
Yes, it's fixed here!
--
Greetings
Pete
<\
\__ O __O
| O\ _\\/\-% _`\<,
'()-'-(_)--(_) (_)/(_)
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#9927: 24.1.50; unexec/unexmacosx doesn't grok GCC 4.6+ sections
2014-09-17 18:39 ` Paul Eggert
2014-09-17 19:48 ` Glenn Morris
2014-09-17 21:00 ` Peter Dyballa
@ 2014-09-17 22:20 ` Peter Dyballa
2 siblings, 0 replies; 29+ messages in thread
From: Peter Dyballa @ 2014-09-17 22:20 UTC (permalink / raw)
To: Paul Eggert; +Cc: 9927
Am 17.09.2014 um 20:39 schrieb Paul Eggert:
> does it work for you?
On Mac OS X 10.6.8, Snow Leopard, with intel Core2 hardware your patch works with GCC 4.6.4, 4.7.3 and 4.8.2. Although this is 64-bit hardware I built GNU Emacs as a 32-bit application with wide ints. If you want I can check with 64-bit builds, for which I first would need to build and install the compilers (the 32-bit software comes the Fink Project which starter 32 bit, the 64-bit software comes from the MacPorts project). I could also check with other versions of GNU Emacs, even with GNU Emacs 24.1.50 – its sources are certainly saved in some (Time Machine) backup…
I started a build on PPC hardware (PowerPC 7447A) on Mac OS X 10.4.11 (Tiger). I'll be able to report after sleep…
--
Greetings
Pete
"I myself have never been able to find out precisely what feminism is; I only know that people call me a feminist whenever I express sentiments that differentiate me from a doormat or a prostitute."
– Dame Rebecca West
^ permalink raw reply [flat|nested] 29+ messages in thread