Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
[Solved] dyld: unknown external relocation type
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Solved] dyld: unknown external relocation type

Hi list,
I think it might save some time to other people so i'm putting some explanation here (I hope I won't breach any NDA)
thanks to apple bug management, I've learned the answer about why when mixing asm ppc code + C dynamic library, I was obtaining

dyld: unknown external relocation type
Trace/BPT trap

(a very small minimal tarball proof of behaviour follows at the end)

*** CONTEXT ****
1) a dynamic lib contains a variable named trail ( int trail; for the sake of clarity)
2) an object code written in ppc asm try to access/modify this variable using

addis	r15,0,ha16(_trail+0)
addi	r15,r15,lo16(_trail+0)

3) when one compiles the dynamic lib using standard option and linking with the asm code (adding -Wl,read_only_relocs,suppress)

gcc module.c -o libmodule.dylib -malign-natural -install_name `pwd`/ libmodule.dylib -compatibility_version 1 -current_version 1.0 - single_module -dynamiclib -arch ppc -flat_namespace -undefined suppress -Wl,-read_only_relocs,suppress
gcc test.c link.s -o test ./libmodule.dylib -Wl,- read_only_relocs,suppress

the code crashes with

dyld: unknown external relocation type
Trace/BPT trap

The two assembly commands load the absolutes address of _trail into R15. Doing so is fine if _trail is ultimately in the same linkage unit. _trail is in libmodule.dylib.
For this to work, at runtime the dynamic loader (dyld) would have to rewrite the two instructions. Normally dyld only updates data pointers.
One work around is to make libdyalog an archive (e.g. libdyalog.a) and link that with pere.s. Then all the code would be in the same linkage unit, so there would be no need for runtime text relocs.
The runtime (dyld) does support text relocs (updating instructions) for i386, but you need to link with -read_only_relocs suppress.


declare the variable in a dummy .c, make it extern in the module file, the dummy .c file will have to be linked with the assembly code and then it will work

*** Related question *******

Maybe it's related to a bug the ghc haskell compiler (http:// where the leopard (I know my bug is tiger related but I don't own leopard so I can't test) linker seems to have
troubles to handle the sequence

lis r,hi16(s+k)
 ori r,r,lo16(s+k)

as a workaround they suggest  using

lis r,ha16(s+k)
la r,lo16(s+k)(r)

*** in LinuxPPC ? ***
If someone knows if it works the same in LinuxPPC, I would be happy to know

Thanks for reading, I hope it could be usefull for some people,

Djamé Seddah

ps : the following archive (small, <1k) contains a small behaviour showing the unexpected behaviour (I don't know if it's a bug or not, at least it's
a strong behaviour difference between tiger x86's dyld and tiger ppc's dyld)
4 files (module.c, link.s, test.c and, http://

//### module.c
#include <stdio.h>
int trail;
void init_module(){
printf("libmodule.dylib : I'm in libmodule.dylib and trail = %d \n",trail);
printf("libmodule.dylib: now trail = %d\n",trail);
//# link.s
.text ; code section

.globl _modify_trail
lis r4, ha16(_trail) ; first half of string
addi r4, r4, lo16(_trail) ; second half of string
li r5,99 ; load a random value
stw r5,0(r4) ; put it on _trail
xor. r3, r3, r3 ; zero out register 3
mr r3, r11
blr ;branch to instruction register ( exit )
//# test.c
#include <stdio.h>
extern int trail;
int main(char **argv,int argn){
printf(" test.c : before modif by libmodule.dylib trail = %d \n",trail);
printf("test.c: after modif by libmodule.dylib trail = %d\n",trail);
printf("test.c: after modif by link.s trail = %d\n",trail);


_______________________________________________ Do not post admin requests to the list. They will be ignored. Unix-porting mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden

Visit the Apple Store online or at retail locations.

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.