On 16/09/2010 04:09, Ben Lippmeier wrote:
On 16/09/2010, at 9:56 AM, Manuel M T Chakravarty wrote:
I don't know what the difference between "relocatable contents"
and "the whole .o file" is, or how many sections we're using. In
my build tree from Sept 9th the resulting file is 44MB and it
made that ok.
For details on the file format:
* ABI reference:
http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html
* Background info:
http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachOTopics/0-Introduction/introduction.html
Alright, so a section is a fixed purpose region of a segment. They're
all predefined, so we can't work around the problem by making more.
Using otool, the sizes of the sections in HSghc-6.13.20100909.o for
my working build of Sept 9th are:
Segment section size (hex) size (dec) __TEXT __text
ebed60 15,461,728 __TEXT __string 0 __TEXT
__picsymbol_stub 0 __TEXT __symbol_stub 0 __TEXT
__const 8e3c0 __TEXT __literal4 0 __TEXT
__literal8 0
__DATA __data 92130 __DATA __la_symbol_ptr 0
__DATA __nl_symbol_ptr 90 __DATA __dyld 0
__DATA __const 54bb0 __DATA __mod_init_func 0
__DATA __mod_term_func 0 __DATA __bss 0
__DATA __common 0
__IMPORT __jump_table 0 __IMPORT __pointers 4
The size of each section can only be 0xffffff (16 MiB). That means
we'd already used 92% of the available space in the text section
before the recent changes.
Really? Surely the size of the text section can't be limited to 16MB,
there must be shared libraries that exceed that. If the limit is really
on the size of a section, then we'll run into trouble with the dynamic
version of the GHC library too, and splitting it up would be painful (we
assume that all modules of a package reside in the same shared library,
to avoid having to make expensive dynamic references all the time).
Isn't it just that you can't have a "scattered relocation" with an
offset greater than 0xffffff?
So if it is due to a scattered relocation, why is there a scattered
relocation at all? I thought these were to support the PPC instruction
set where you have to split addresses into multiple pieces, and x86
doesn't need them.
Cheers,
Simon
We can also look at the sizes of the individual .o files we're trying
to link together. This is with the unneeded NCGs already removed:
broken working Total size of .o files 98.024 MB
88.896 MB Total size of text in .o files 16.084 MB 14.317 MB
The size of the text section in HSghc is larger than the text of all
the .o files by about 8%. Maybe this is padding, not sure.
(15.461 MB / 14.317 MB) - 1) * 100 = 8%
Using this figure, if we were to link together all the .o files in
the broken version, then the size of the text section would need to
be:
16.084 MB * 1.08 = 17.370 MB
So I reckon we need to cut out at least (17.370 MB - 16.777 MB =
0.593 MB) of bloat for this to link.
For interests sake, I also looked at the total size of the text
sections for the .o files belonging to each NCG:
Alpha: 1k (it's already commented out) SPARC: 250k PPC: 260k x86:
378k
I'll try rolling back the changes to the containers library, but we
may want to break up HSghc and hack GHCi as a contingency plan. If we
don't break it up we'll still be close to the size limit, and might
encounter problems trying to patch the 7.0 stable branch.
Ben.
_______________________________________________ Cvs-ghc mailing list
[email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
