search for: __compact_unwind

...000073] Running...* *jitLink_MachO: magic = 0xfeedfacf, identifier = "llvm-link.submodule-jitted-objectbuffer"* *jitLink_MachO: cputype = 0x0100000c, cpusubtype = 0x00000000* *Creating normalized sections...* * __text: 0x0000000000000000 -- 0x0000000000000064, align: 4, index: 0* * __compact_unwind: 0x0000000000000068 -- 0x0000000000000088, align: 8, index: 1* *Creating normalized symbols...* * ltmp0: value = 0x0000000000000000, type = 0x0e, desc = 0x0000, sect = 0* * ltmp1: value = 0x0000000000000068, type = 0x0e, desc = 0x0000, sect = 1* * _main: value = 0x0000000000000000, type = 0x...

...3 flags (none) Section 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 0x0000...

...ed-objectbuffer" > >> > >> jitLink_MachO: cputype = 0x0100000c, cpusubtype = 0x00000000 > >> > >> Creating normalized sections... > >> > >> __text: 0x0000000000000000 -- 0x0000000000000064, align: 4, index: 0 > >> > >> __compact_unwind: 0x0000000000000068 -- 0x0000000000000088, align: 8, > index: 1 > >> > >> Creating normalized symbols... > >> > >> ltmp0: value = 0x0000000000000000, type = 0x0e, desc = 0x0000, sect = > 0 > >> > >> ltmp1: value = 0x0000000000000068, t...

...30f4e00).__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} @0x0000000112efcd68 > > ) > > so it seems like despite knowing the correct load address for the __debug_info section, it's still so...

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

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

Hello, I am trying to run this basic C++ hello-world code in my iOS app that has LLVM libraries linked in (the app runs on the actual device - iPad Pro, iOS 13.4.1). #include <iostream> int main (int argh, char *argv[]) { std::cout << "Hello World!" << std::endl; return 0; } So below is the break down of the steps that I do: First I compile this code to an