search for: __ld

..._DWARF.__debug_loc > 0x00000007 dwarf-ranges 0x00000c4b 0x00000000 0x02000000 JIT(0x7fc4230f4e00).__DWARF.__debug_ranges > 0x00000300 container [0x0000000112efce80-0x0000000112efcec0)* 0x00000c50 0x00000040 0x00000000 JIT(0x7fc4230f4e00).__LD > 0x00000008 regular [0x0000000112efce80-0x0000000112efcec0) 0x00000c50 0x00000040 0x02000000 JIT(0x7fc4230f4e00).__LD.__compact_unwind > > (the relocated address is > > julia> datapointer(filter(s->s.sectname == "__debug_info",sects)[1]) > Ptr{Uint8...

I didn't get to work on this more last week, but I'll look at incorporating that suggestion. The other question of course is how to do this in LLDB. Right, now what I'm doing is going through and adjusting the load address of every leaf in the section tree. That basically works and gets me backtraces with the correct function names and the ability to set breakpoints at functions in

...sectname __text segname __TEXT addr 0x0000000000000000 size 0x00000000000006b6 offset 464 align 2^4 (16) reloff 2768 nreloc 9 type S_REGULAR attributes PURE_INSTRUCTIONS SOME_INSTRUCTIONS reserved1 0 reserved2 0 Section sectname __compact_unwind segname __LD addr 0x00000000000006b6 size 0x00000000000000e0 offset 2182 align 2^0 (1) reloff 2840 nreloc 7 type S_REGULAR attributes DEBUG reserved1 0 reserved2 0 Section sectname __eh_frame segname __TEXT addr 0x0000000000000798 size 0x0000000000000168...

...18: /lib/clang/8.0.0/include/__stddef_max_align_t.h:40:3: error: typedef redefinition with different types ('struct max_align_t' vs 'struct max_align_t') } max_align_t; ^ /include/bits/alltypes.h:49:54: note: previous definition is here typedef struct { long long __ll; long double __ld; } max_align_t; ^ 1 error generated. I've asked to the musl's maintainer and said that clang should not provide std* files that are already present in musl. He also said that the include order should be inversed to use '/include'...

Hi Kent, My guess is you are getting some new bit of info in your object files and your ranlib(1) is older and doesn't know about it. If you can send me the .o file or the output of otool(1) with the -hlv options on your object file I can take a look. Kev P.S. you can find out the version of ranlib(1) you have by running strings(1) on it and grep(1)'ing for the string

Ran into this today -- rebuilt the SVN Trunk for this morning of LLVM+CLANG. Now every time my builds try and make a library from .o files, ranlib complains about 'malformed object' files. This is with OS X 10.7.4, and the binary tools from XCode 4.4.1 ld -v @(#)PROGRAM:ld PROJECT:ld64-127.2 llvm version 3.0svn, from Apple Clang 3.0 (build 211.12) ranlib doesn't tell you what