unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#13528: 24.3.50; "find_emacs_zone_regions: too many regions" --with-wide-int on PPC 7447A Mac OS X 10.5.8
@ 2013-01-21 22:19 Peter Dyballa
  2013-01-22 20:46 ` bug#13528: " Paul Eggert
  0 siblings, 1 reply; 12+ messages in thread
From: Peter Dyballa @ 2013-01-21 22:19 UTC (permalink / raw)
  To: 13528

Hello!

	In GNU Emacs 24.3.50.1 (powerpc-apple-darwin9.8.0, X toolkit, Xaw3d  
scroll bars)
	 of 2013-01-21 on Latsche.local
	Bzr revision: 111577 dmantipov@yandex.ru-20130121170109-qsz6nomnl47c53nx
	Windowing system distributor `The X.Org Foundation', version  
11.0.11399901
	Configured using:
	 `configure --without-pop --without-sound --without-xim --without-gpm
	 --without-dbus --without-gconf --without-gsettings --without-selinux
	 --without-imagemagick --with-x-toolkit=athena
	 --disable-ns-self-contained --x-libraries=/usr/X11/lib
	 --x-includes=/usr/X11/include
	 --enable-locallisppath=/Library/Application
	 Support/Emacs/calendar24:/Library/Application Support/Emacs CFLAGS=-g
	 -ggdb3 -H -pipe -fPIC -fno-common -Os -mcpu=7450 -mtune=G4
	 CPPFLAGS=-I/sw/include LDFLAGS=-L/sw/lib -v -Wl,-v
	 -Wl,-dead_strip_dylibs -Wl,-bind_at_load -Wl,-t GCC=gcc-4.2  
CPP=cpp-4.2
	 CXX=c++-4.2 LD=c++-4.2
	PKG_CONFIG_PATH=/sw/lib/pkgconfig:/sw/share/pkgconfig:/usr/X11/lib/ 
pkgconfig:/usr/lib/pkgconfig:/usr/lib/pkgconfig'

compiles and builds fine, but when I add --with-wide-int to the  
configure options compilations ends here:

	 0x28f6000 (sz:   0x3fff/  0x5000)
	unexec: find_emacs_zone_regions: too many regions
	make[2]: *** [bootstrap-emacs] Error 1
	make[2]: Leaving directory `.../emacs-24.3.50/src'

It happens for both the X11 client and the NS variant. If I substitute  
-Os with -O0 both compile.

--
Greetings

   Pete
               <\
                 \__     O                       __O
                 | O\   _\\/\-%                _`\<,
                 '()-'-(_)--(_)               (_)/(_)






^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#13528: "find_emacs_zone_regions: too many regions" --with-wide-int on PPC 7447A Mac OS X 10.5.8
  2013-01-21 22:19 bug#13528: 24.3.50; "find_emacs_zone_regions: too many regions" --with-wide-int on PPC 7447A Mac OS X 10.5.8 Peter Dyballa
@ 2013-01-22 20:46 ` Paul Eggert
  2013-01-22 22:29   ` Peter Dyballa
  2013-01-22 23:35   ` Peter Dyballa
  0 siblings, 2 replies; 12+ messages in thread
From: Paul Eggert @ 2013-01-22 20:46 UTC (permalink / raw)
  To: Peter Dyballa; +Cc: 13528

Thanks, does the following fix things for you, and if so, how many
regions does Emacs report when dumping?

=== modified file 'src/unexmacosx.c'
--- src/unexmacosx.c	2013-01-01 09:11:05 +0000
+++ src/unexmacosx.c	2013-01-22 20:46:07 +0000
@@ -437,7 +437,7 @@ build_region_list (void)
 }
 
 
-#define MAX_UNEXEC_REGIONS 400
+#define MAX_UNEXEC_REGIONS 800
 
 static int num_unexec_regions;
 typedef struct {






^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#13528: "find_emacs_zone_regions: too many regions" --with-wide-int on PPC 7447A Mac OS X 10.5.8
  2013-01-22 20:46 ` bug#13528: " Paul Eggert
@ 2013-01-22 22:29   ` Peter Dyballa
  2013-01-22 22:37     ` Paul Eggert
                       ` (2 more replies)
  2013-01-22 23:35   ` Peter Dyballa
  1 sibling, 3 replies; 12+ messages in thread
From: Peter Dyballa @ 2013-01-22 22:29 UTC (permalink / raw)
  To: Paul Eggert; +Cc: 13528


Am 22.01.2013 um 21:46 schrieb Paul Eggert:

> Thanks, does the following fix things for you, and if so, how many
> regions does Emacs report when dumping?


I did not try that patch yet – because I was compiling GNU Emacs from  
the same code basis as yesterday, now without the bootstrap option.  
And it builds with -Os, and if fails when building the bootstrap  
targets with -Os!

I saved all *compilation* buffers. Comparing "make bootstrap with -Os"  
with "make with -Os" leads, when I leave away the initial bootstrap  
paraphernalia, to these "major differences:

make bootstrap:
	make[2]: Leaving directory `.../emacs-24.3.50/lib'
	cd lib-src && make all -w                         \
	  CC='gcc -std=gnu99' CFLAGS='-g -ggdb3 -H -pipe -fPIC -fno-common - 
Os -mcpu=7450 -mtune=G4' CPPFLAGS='-I/sw/include' \
	  LDFLAGS='-L/sw/lib -v -Wl,-v -Wl,-dead_strip_dylibs -Wl,- 
bind_at_load -Wl,-t -L/usr/X11/lib' MAKE='make'
	
	make[2]: Leaving directory `.../emacs-24.3.50/lib-src'
	boot=bootstrap-emacs;                         \
	if [ ! -x "src/$boot" ]; then                                     \
	    cd src; make all -w                                   \
	      CC='gcc -std=gnu99' CFLAGS='-g -ggdb3 -H -pipe -fPIC -fno- 
common -Os -mcpu=7450 -mtune=G4' CPPFLAGS='-I/sw/include'         \
	      LDFLAGS='-L/sw/lib -v -Wl,-v -Wl,-dead_strip_dylibs -Wl,- 
bind_at_load -Wl,-t -L/usr/X11/lib' MAKE='make'  
BOOTSTRAPEMACS="$boot"; \
	fi;

make:
	make[1]: Leaving directory `.../emacs-24.3.50/lib'
	cd lib-src && make all                          \
	  CC='gcc -std=gnu99' CFLAGS='-g -ggdb3 -H -pipe -fPIC -fno-common - 
Os -mcpu=7450 -mtune=G4' CPPFLAGS='-I/sw/include' \
	  LDFLAGS='-L/sw/lib -v -Wl,-v -Wl,-dead_strip_dylibs -Wl,- 
bind_at_load -Wl,-t -L/usr/X11/lib' MAKE='make'
	
	make[1]: Leaving directory `.../emacs-24.3.50/lib-src'
	boot=bootstrap-emacs;                         \
	if [ ! -x "src/$boot" ]; then                                     \
	    cd src; make all                                    \
	      CC='gcc -std=gnu99' CFLAGS='-g -ggdb3 -H -pipe -fPIC -fno- 
common -Os -mcpu=7450 -mtune=G4' CPPFLAGS='-I/sw/include'         \
	      LDFLAGS='-L/sw/lib -v -Wl,-v -Wl,-dead_strip_dylibs -Wl,- 
bind_at_load -Wl,-t -L/usr/X11/lib' MAKE='make'  
BOOTSTRAPEMACS="$boot"; \
	fi;

which certainly is not significant. But then there are some during the  
dumping step:

make bootstrap:
	34 LC_LOAD_DYLIB          52
	 0x14fc080 (sz:   0x2cf1/  0x3f0a)
	 0x1400000 (sz:  0x6b5e4/ 0xfc080)
	 0x27f8000 (sz:   0x6d58/  0x7f80)
	 0x2000000 (sz: 0x6d5600/0x7f8000)
	 0x17f8000 (sz:   0x3fff/  0x5000)


make:
	34 LC_LOAD_DYLIB          52
	 0x14fc080 (sz:   0x2558/  0x3f0a)
	 0x1400000 (sz:  0x2e950/ 0xfc080)
	 0x27f8000 (sz:   0x63b8/  0x7f80)
	 0x2000000 (sz: 0x639917/0x7f8000)
	 0x13f3000 (sz:   0x3fff/  0x5000)

This is just a snapshot from the start, more and subtle differences  
follow like for example (same "line numbers"):

	 0x17b0000 (sz:   0x3fff/  0x5000)
	 0x17a9000 (sz:   0x63c7/  0x7000)
	 0x17a2000 (sz:   0x63bb/  0x7000)
	 0x179d000 (sz:   0x3fff/  0x5000)

vs.

	 0x17d4000 (sz:   0x3fff/  0x5000)
	 0x13d2000 (sz:   0x3fff/  0x5000)
	 0x17cd000 (sz:   0x63bb/  0x7000)
	 0x13cd000 (sz:   0x3fff/  0x5000)

Before I'll try the patch I'll make bootstrap with -O0 so see whether  
this works – unless you recommend something different.

BTW, how do I count these regions? On Mac OS X this count is not  
directly reported and I have no idea how determine the number.

My tries today were 'make clean', configure ..., make.

--
Greetings

   Pete

"A TRUE Klingon warrior does not comment his code."






^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#13528: "find_emacs_zone_regions: too many regions" --with-wide-int on PPC 7447A Mac OS X 10.5.8
  2013-01-22 22:29   ` Peter Dyballa
@ 2013-01-22 22:37     ` Paul Eggert
  2013-01-22 23:11       ` Peter Dyballa
  2013-01-24 21:01     ` Peter Dyballa
  2013-01-25 16:45     ` Peter Dyballa
  2 siblings, 1 reply; 12+ messages in thread
From: Paul Eggert @ 2013-01-22 22:37 UTC (permalink / raw)
  To: Peter Dyballa; +Cc: 13528

On 01/22/13 14:29, Peter Dyballa wrote:
> BTW, how do I count these regions? On Mac OS X this count is not directly reported and I have no idea how determine the number.

Sorry, I don't use OS X, I'm just trying to help remotely.
I'd just take the number of text lines that look like
those regions, as Emacs appears to output one line per region.





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#13528: "find_emacs_zone_regions: too many regions" --with-wide-int on PPC 7447A Mac OS X 10.5.8
  2013-01-22 22:37     ` Paul Eggert
@ 2013-01-22 23:11       ` Peter Dyballa
  0 siblings, 0 replies; 12+ messages in thread
From: Peter Dyballa @ 2013-01-22 23:11 UTC (permalink / raw)
  To: Paul Eggert; +Cc: 13528


Am 22.01.2013 um 23:37 schrieb Paul Eggert:

> On 01/22/13 14:29, Peter Dyballa wrote:
>> BTW, how do I count these regions? On Mac OS X this count is not  
>> directly reported and I have no idea how determine the number.
>
> Sorry, I don't use OS X, I'm just trying to help remotely.
> I'd just take the number of text lines that look like
> those regions, as Emacs appears to output one line per region.



After the text "Dumping under the name emacs" follows

--- List of All Regions --- = 153 lines
+
--- List of Regions to be Dumped --- = 144 lines
followed by
--- Header Information ---

So it's presumingly 397 regions, less than the 400.

The 'make bootstrap' with -O0 fails as well.

I'm going to patch now…

--
Greetings

   Pete
               <\
                 \__     O                       __O
                 | O\   _\\/\-%                _`\<,
                 '()-'-(_)--(_)               (_)/(_)






^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#13528: "find_emacs_zone_regions: too many regions" --with-wide-int on PPC 7447A Mac OS X 10.5.8
  2013-01-22 20:46 ` bug#13528: " Paul Eggert
  2013-01-22 22:29   ` Peter Dyballa
@ 2013-01-22 23:35   ` Peter Dyballa
  2013-01-23  1:57     ` Paul Eggert
  1 sibling, 1 reply; 12+ messages in thread
From: Peter Dyballa @ 2013-01-22 23:35 UTC (permalink / raw)
  To: Paul Eggert; +Cc: 13528


Am 22.01.2013 um 21:46 schrieb Paul Eggert:

> === modified file 'src/unexmacosx.c'
> --- src/unexmacosx.c	2013-01-01 09:11:05 +0000
> +++ src/unexmacosx.c	2013-01-22 20:46:07 +0000
> @@ -437,7 +437,7 @@ build_region_list (void)
> }
>
>
> -#define MAX_UNEXEC_REGIONS 400
> +#define MAX_UNEXEC_REGIONS 800
>
> static int num_unexec_regions;
> typedef struct {


With this patch applied, optimisation at -O0, 'make bootstrap'  
delivers 124 + 116 lines plus 447 lines after the lines

	32 LC_LOAD_DYLIB          52
	33 LC_LOAD_DYLIB          56
	34 LC_LOAD_DYLIB          52

The build now fails with:

	Writing LC_LOAD_DYLIB     command
	Writing LC_LOAD_DYLIB     command
	Writing LC_LOAD_DYLIB     command
	unexec: not enough room for load commands for new __DATA segments
	make[2]: *** [bootstrap-emacs] Error 1

--
Greetings

   Pete

If it dies, it's biology.  If it blows up, it's chemistry. If it  
doesn't work, it's physics.
			– University washroom sgraffito






^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#13528: "find_emacs_zone_regions: too many regions" --with-wide-int on PPC 7447A Mac OS X 10.5.8
  2013-01-22 23:35   ` Peter Dyballa
@ 2013-01-23  1:57     ` Paul Eggert
  2013-01-23 10:40       ` Peter Dyballa
  2013-01-23 23:37       ` Peter Dyballa
  0 siblings, 2 replies; 12+ messages in thread
From: Paul Eggert @ 2013-01-23  1:57 UTC (permalink / raw)
  To: Peter Dyballa; +Cc: 13528

On 01/22/2013 03:35 PM, Peter Dyballa wrote:
>     unexec: not enough room for load commands for new __DATA segments

Presumably this line in unexmacosx.c needs to be changed:

static unsigned long text_seg_lowest_offset = 0x10000000;

I'd try changing it to (say) 0x20000000, and then see what
Emacs says is the "Lowest offset of all sections in __TEXT segment".





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#13528: "find_emacs_zone_regions: too many regions" --with-wide-int on PPC 7447A Mac OS X 10.5.8
  2013-01-23  1:57     ` Paul Eggert
@ 2013-01-23 10:40       ` Peter Dyballa
  2013-01-23 23:37       ` Peter Dyballa
  1 sibling, 0 replies; 12+ messages in thread
From: Peter Dyballa @ 2013-01-23 10:40 UTC (permalink / raw)
  To: Paul Eggert; +Cc: 13528


Am 23.01.2013 um 02:57 schrieb Paul Eggert:

> On 01/22/2013 03:35 PM, Peter Dyballa wrote:
>>    unexec: not enough room for load commands for new __DATA segments
>
> Presumably this line in unexmacosx.c needs to be changed:
>
> static unsigned long text_seg_lowest_offset = 0x10000000;
>
> I'd try changing it to (say) 0x20000000, and then see what
> Emacs says is the "Lowest offset of all sections in __TEXT segment".


This change leads to the same failure. The requested value ranges from  
0x1218 (from my tries with Xaw3d variant and GCC 4.2, yesterday) up to  
0x20a0 (NS variant with GCC 4.0, last summer). The last (failed)  
compilation reports 0x139c.

--
Greetings

   Pete

If my theory of relativity is proven successful, Germany will claim me  
as a German, and France will declare that I am a citizen of the world.  
Should my theory prove untrue, France will say that I am a German, and  
Germany will declare that I am a Jew.
				– Albert Einstein, 1929






^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#13528: "find_emacs_zone_regions: too many regions" --with-wide-int on PPC 7447A Mac OS X 10.5.8
  2013-01-23  1:57     ` Paul Eggert
  2013-01-23 10:40       ` Peter Dyballa
@ 2013-01-23 23:37       ` Peter Dyballa
  1 sibling, 0 replies; 12+ messages in thread
From: Peter Dyballa @ 2013-01-23 23:37 UTC (permalink / raw)
  To: Paul Eggert; +Cc: 13528

I have two package managers installed on my Mac, Fink and MacPorts, to install all the necessary and up-to-date libraries and software. Until now I was using libraries from Fink. An hour ago I configured, after a 'make distclean', to use MacPorts – and GNU Emacs builds as X client with wide ints. So I am considering that Fink is a bit defective…

Rebuilding dozens of packages can take days presumingly!

--
Greetings

  Pete


"Evolution"            o           __o                     _o _
          °\___o      /0~         -\<,              ^\___ /=\\_/-%
oo~_______ /\ /\______/ \_________O/ O_______________o===>-->O--o____






^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#13528: "find_emacs_zone_regions: too many regions" --with-wide-int on PPC 7447A Mac OS X 10.5.8
  2013-01-22 22:29   ` Peter Dyballa
  2013-01-22 22:37     ` Paul Eggert
@ 2013-01-24 21:01     ` Peter Dyballa
  2013-01-25 16:45     ` Peter Dyballa
  2 siblings, 0 replies; 12+ messages in thread
From: Peter Dyballa @ 2013-01-24 21:01 UTC (permalink / raw)
  To: Paul Eggert; +Cc: 13528


Am 22.01.2013 um 23:29 schrieb Peter Dyballa:

> I did not try that patch yet – because I was compiling GNU Emacs  
> from the same code basis as yesterday, now without the bootstrap  
> option. And it builds with -Os, and if fails when building the  
> bootstrap targets with -Os!

I found the reason for the different behaviour: 'make bootstrap' seems  
to throw away the Makefile(s) built by configure and it then runs  
config.status. Without setting PATH the wrong utilities are found and  
the built can become a mix of system, Fink, and MacPorts software.  
This cannot work.

To 'make bootstrap' I'll have to rename Fink's /sw or MacPorts' /opt –  
which also means that I won't have access to all compilers installed.

--
Greetings

   Pete

Hard Disk, n.:
	A device that allows users to delete vast quantities of data with  
simple mnemonic commands.






^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#13528: "find_emacs_zone_regions: too many regions" --with-wide-int on PPC 7447A Mac OS X 10.5.8
  2013-01-22 22:29   ` Peter Dyballa
  2013-01-22 22:37     ` Paul Eggert
  2013-01-24 21:01     ` Peter Dyballa
@ 2013-01-25 16:45     ` Peter Dyballa
  2013-02-08 16:25       ` Paul Eggert
  2 siblings, 1 reply; 12+ messages in thread
From: Peter Dyballa @ 2013-01-25 16:45 UTC (permalink / raw)
  To: Paul Eggert; +Cc: 13528


Am 22.01.2013 um 23:29 schrieb Peter Dyballa:

> I did not try that patch yet – because I was compiling GNU Emacs  
> from the same code basis as yesterday, now without the bootstrap  
> option. And it builds with -Os, and if fails when building the  
> bootstrap targets with -Os!

I have indeed undone all patches to src/unexmacosx.c. Within the  
clearly set build environments for configure, make, make install GNU  
Emacs builds without problems. I updated the sources and still no  
problem. The real problem is that 'make bootstrap' does not honour the  
previous configure step and tries something that is bound to fail. If  
this behaviour continues, the sequence of make distclean, configure,  
make, make install seems to be a valid work-around.

My bug report was wrong: I did not see what 'make bootstrap' was  
really performing.

--
Greetings

   Pete

The human brain operates at only 10% of its capacity. The rest is  
overhead for the operating system.






^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#13528: "find_emacs_zone_regions: too many regions" --with-wide-int on PPC 7447A Mac OS X 10.5.8
  2013-01-25 16:45     ` Peter Dyballa
@ 2013-02-08 16:25       ` Paul Eggert
  0 siblings, 0 replies; 12+ messages in thread
From: Paul Eggert @ 2013-02-08 16:25 UTC (permalink / raw)
  To: Peter Dyballa; +Cc: 13528-done

On 01/25/2013 08:45 AM, Peter Dyballa wrote:
> My bug report was wrong: I did not see what 'make bootstrap' was really performing.

OK, thanks for following up; marking this as done.





^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2013-02-08 16:25 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-21 22:19 bug#13528: 24.3.50; "find_emacs_zone_regions: too many regions" --with-wide-int on PPC 7447A Mac OS X 10.5.8 Peter Dyballa
2013-01-22 20:46 ` bug#13528: " Paul Eggert
2013-01-22 22:29   ` Peter Dyballa
2013-01-22 22:37     ` Paul Eggert
2013-01-22 23:11       ` Peter Dyballa
2013-01-24 21:01     ` Peter Dyballa
2013-01-25 16:45     ` Peter Dyballa
2013-02-08 16:25       ` Paul Eggert
2013-01-22 23:35   ` Peter Dyballa
2013-01-23  1:57     ` Paul Eggert
2013-01-23 10:40       ` Peter Dyballa
2013-01-23 23:37       ` Peter Dyballa

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).