MachO: relocation offset is out of range

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Mikl?s Fazekas - 30 Jan 2004 08:27 GMT

When linking our large (~27 MB) MachO application in debug mode we
get the following error:

Error : relocation offset for address 01007A08 in object
'___keymgr_dwarf2_register_sections' is out of range

Is this because of a size limitation?!
It used to work until yesterday. And optimized version still works.

Adding "-fold multidefs" to the debug problem solved the problem, but
i guess only temporary. And it slowed down the linking.

Is it a limit in MachO object format, or it's the limit of mwld?!
Is this limit beacuse of the size of the code, or other like the use
of globals, etc.
How can we detect if we're near to that limit from the .map file?! (So
we can prepare to this...)

Regards,
Miklos

Reply to this Message

MW Ron - 30 Jan 2004 19:09 GMT

Here is a response from our Mach-O engineers.

>When linking our large (~27 MB) MachO application in debug mode we
>get the following error:
>
> Error : relocation offset for address 01007A08 in object
> '___keymgr_dwarf2_register_sections' is out of range

Scattered relocation records only support a 24 bit address (~16 MB),
(pointing to the value to fix up) which to make it more useful is
computed as a 24-bit offset from the VM address of the first SEGMENT
(normally the __TEXT segment).

__keymgr_dwarf2_register_sections shows up because it is unable to
generate the relocation record for the lazy pointer which it used to
call __keymgr_dwarf2_register_sections in the System framework.

>Is this because of a size limitation?!
>It used to work until yesterday. And optimized version still works.

I am amazed that it worked as long as it has if it is truely a 27MB
application (perhaps a large part of that 27MB is the symbol table).

>Adding "-fold multidefs" to the debug problem solved the problem, but
>i guess only temporary. And it slowed down the linking.

That just indicates that the templates used have a fair amount of
implementation which are identical (I guess that means that it works,
but if the slow down is a problem we can look into it, but we don't
really have an example where the slow down is noticeable)

>Is it a limit in MachO object format, or it's the limit of mwld?!

Mach-O

>Is this limit beacuse of the size of the code, or other like the use
>of globals, etc.

The size of the code effects things since an application is laid out:

vm_addr ===>>>>
__TEXT segment
<loader commands>
__TEXT,__text
<code sections>
__DATA segment (read/write data)
<data>

Generally the only relocation records update values in the __DATA
segment which contains: staticly initialized pointers to other
objects, and the runtime required lazy pointers and non-lazy pointers.

>How can we detect if we're near to that limit from the .map file?! (So
>we can prepare to this...)

The highest address needing relocation - vm_addr of the application
(usually 0x1000)

In this case 01007A08 is 6A08 past the max which can be reached
(assuming the default VM address of 0x1000).

The response from Apple in previous cases like this was to tell the
user to split out a dylib to make the main program smaller.

Ron

Signature

Metrowerks, maker of CodeWarrior - "Software Starts Here"
Ron Liechty - MWRon@metrowerks.com - <http://www.metrowerks.com>

Reply to this Message

Mac Forum / Programming / CodeWarrior / January 2004

MachO: relocation offset is out of range