i386/OSX build broken

[Manuel M T Chakravarty]

Simon Marlow:
> 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.

Scattered relations are not used on X86_64, but they are used on i386 (not just PPC).  They are definitely used for lazy pointers.  (It says so in the ABI document.)  I vaguely remember, I have seen them used in other situations, too, when I debugged Linker.c for Snow Leopard.  For example, the GMP library uses some global variables to determine the routines used for memory allocation.  I think the references to these global pointers were scattered relocations, too.

Manuel