Error with apple's linker

Hi all,

I'm having an issue with the ld linker on MacOSX (10.5). I have generated a large .s file with llc and the relocation-model=pic argument. When I ask the linker to create the .dylib file, I get this error:

ld: double split seg info for same address
collect2: ld returned 1 exit status

The generated .s file for Linux works fine with Linux's ld linker. If anyone has an idea of what's happening with apple's ld, I'd be happy to hear it.

Here's the full context:
With VMKit's compiler, I create a .bc file of the standard Java library. I then run the -std-compile-opts optimizations, so the .bc file passes verification. I generate the .s file with the following command line:

llc -relocation-model=pic -disable-fp-elim myfile.bc

Finally, I use LLVM's Makefile machinery to create a .dylib file from the .s file.

Cheers,
Nicolas

Hi Nicolas,

Do you have know whether this is a regression or not?

Either way, could you perhaps file a PR and attach the test case?

- Daniel

Background:
In Mac OS X 10.5 and later, OS dylibs are copied into something called the dyld shared cache. In the cache all the dylibs are bound to one another, which improves launch time of all processes. The shared cache has a funny constraint where all read-only pages need to be continuous. This requirement means the __TEXT and __DATA segments of each dylib need to be split apart. The normal PIC codegen uses pc-relative access from code to data, so all those pc-relative addresses need to be altered when a dylib is incorporated into the dyld shared cache. To facilitate that, the linker adds content to each dylib that describes where all the code-to-data references are.

The "double split seg info" error means the linker ran into some case where it does not now how to encode a code-to-data reference. In particular is seems like there is two relocations on the same address??

If you have a test case that reproduces this, I can isolate exactly which instruction in the code is causing the problem.

-Nick
Mac OS X Linker

Hi Nick,

Nick Kledzik wrote:

Background:
In Mac OS X 10.5 and later, OS dylibs are copied into something called the dyld shared cache. In the cache all the dylibs are bound to one another, which improves launch time of all processes. The shared cache has a funny constraint where all read-only pages need to be continuous. This requirement means the __TEXT and __DATA segments of each dylib need to be split apart. The normal PIC codegen uses pc- relative access from code to data, so all those pc-relative addresses need to be altered when a dylib is incorporated into the dyld shared cache. To facilitate that, the linker adds content to each dylib that describes where all the code-to-data references are.

The "double split seg info" error means the linker ran into some case where it does not now how to encode a code-to-data reference. In particular is seems like there is two relocations on the same address??

OK, thanks for the explanation. I have no idea if there are two relocations on the same address. If it's the case and it's incorrect, then it seems it's an llvm bug.

If you have a test case that reproduces this, I can isolate exactly which instruction in the code is causing the problem.

Could a 94MB .bc file be considered as a test case? :slight_smile: I can put that file on some website if you're interested. Reducing it to something more test case-like may require some time.

Thanks,
Nicolas

Hi Daniel,

Daniel Dunbar wrote:

Hi Nicolas,

Do you have know whether this is a regression or not?

I don't think it's a regression, I've been having this error since the first time I tried.

Either way, could you perhaps file a PR and attach the test case?

The test case is rather large (94MB of .bc file) , and I'm not sure how to reduce it. I emailed the mailing list to notify the problem and hope someone would say "ah I know how to fix that problem" :slight_smile:

Nicolas

Daniel Dunbar wrote:

Do you have know whether this is a regression or not?

I don't think it's a regression, I've been having this error since the
first time I tried.

Ok.

Either way, could you perhaps file a PR and attach the test case?

The test case is rather large (94MB of .bc file) , and I'm not sure how
to reduce it. I emailed the mailing list to notify the problem and hope
someone would say "ah I know how to fix that problem" :slight_smile:

Well, I'll let Nick chime in on whether he wants a 94MB test case. :slight_smile:

I presume all the inputs aren't really necessary to trigger the bug.
It may be possible to use delta debugging to minimize the list of
input files needed by only linking a subset of the files (and linking
against an external native built version of the dylib, to resolve
undefined symbols against)...

- Daniel