RuntimeDyld bug in resolving addresses with offset?


I believe I came across a bug in RuntimeDyld. I have the following piece of C code (attached as rtdyldbug.c):

double numbers[5] = {33, 34, 35, 36, 37};

void foo(double val, double other) {
  other[2] += val * numbers[4];

I adapted llvm-rtdyld.cpp to load the .o file of the code above, get a pointer to foo, and invoke it (whole thing is attached as myrtdyld.cpp):

typedef void(*myFun)(double, double*);

int main() {
  std::string funName = "_foo";
  std::string fileName = "rtdyldbug.o";
  myFun fptr = (myFun)getFunctionPointer(funName, fileName);

  double w[5] = {0, 0, 0, 0, 0};
  fptr(4, w);

  printf("%f \n", w[2]);
  return 0;

The printed result should be 148, but its 132. The instruction which reads numbers[4] is

mulsd _numbers+0x00000020(%rip),%xmm0

When I did debugging at the assembly level, I found that the offset 0x20 is ignored. The resolved address points to numbers[0] instead of numbers[4].

I compiled the attached rtdyldbug.c as "clang -c -o rtdyldbug.o rtdyldbug.c". I compiled myrtdyld.cpp as "clang++ -o myrtdyld myrtdyld.cpp `llvm-config --cxxflags --libs all --ldflags`". I did the test on Mac OS with clang version 3.3 (trunk 170267).

Any insights/comments/bug fixes would be appreciated.

-Baris Aktemur

rtdyldbug.c (119 Bytes)

myrtdyld.cpp (5.52 KB)