search for: __eh_frame

...0000 -0400 @@ -1,5 +1,5 @@ ---------------------------------------------------------------------- - File: conftest.o.g.stripped (x86_64) + File: conftest.o.g0.stripped (x86_64) ---------------------------------------------------------------------- Exception handling frame information for section __eh_frame when compiled with Clang 6.0 (3.5svn) but now produces... % diff -u conftest.o.g.stripped.dwarfdump conftest.o.g0.stripped.dwarfdump --- conftest.o.g.stripped.dwarfdump 2015-04-10 21:42:02.000000000 -0400 +++ conftest.o.g0.stripped.dwarfdump 2015-04-10 21:41:52.000000000 -0400 @@ -1,12 +1,12 @@...

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Rafael Espíndola > Sent: Monday, April 27, 2015 2:07 PM > To: Jack Howarth > Cc: LLVM Developers Mailing List > Subject: Re: [LLVMdev] __eh_frame info changes in Clang? > > That looks like a bug. > > From > > http://www.linuxbase.org/betaspecs/lsb/LSB-Core-generic/LSB-Core- > generic/ehframechpt.html > > Version > A 1 byte value that identifies the version number of the frame > information structure. This...

...ing virtual machine how to do it. Problems solved: 1) Do not read the DWARF docs. They give you a general idea but nobody follows it. 2) Do not try to *understand* anything. It is hopeless and you will just lose your time. 3) Try to generate EXACTLY what llvm is generating. So, I extracted the __eh_frame section from a simple C program. otool -s __TEXT __eh_frame hello.o I figure out from the hexadecimal dump where the CIE lies. Then, I generate exactly the same. Then, generate the FDEs for each function. Again, use the dump of the __eh_frame section as a guide but add your own virtual machine...

...onPass16addToPassManagerEPNS_20FunctionPassManagerTERNS_13Analys isUsageE.eh $ nm -m opt | grep __ZN4llvm12FunctionPass16addToPassManagerEPNS_20FunctionPass 001b8d90 (__TEXT,__text) external __ZN4llvm12FunctionPass16addToPassManagerEPNS_20FunctionPa ssManagerTERNS_13AnalysisUsageE 00380b64 (__TEXT,__eh_frame) external __ZN4llvm12FunctionPass16addToPassManagerEPNS_20Functi onPassManagerTERNS_13AnalysisUsageE.eh I will try the CVS version. Thanks, Jing -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060828/9911...

Hi On Mon Jul 27 11:29:44 CDT 2015 I posted a question here about the way llvm implements exceptions in Apple's OS X. Since then I have received ZERO answers. I have solved the problem myself by "disassembling" the messy source code available. I thank everyone for proving me (yet another time) that THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.

...E_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 offset 2408 align 2^3 (8) reloff 0 nreloc 0 type S_COALESCED attributes NO_TOC STRIP_STATIC_SYMS LIVE_SUPPORT reserved1 0 reserved2 0 Load command 1 cmd ?(0x00000029) Unknown load command...

...| Section (__DATA, __mod_init_func): 4 | Section (__DATA, __mod_init_func): 4 Section (__DATA, __bss): 32 | Section (__DATA, __bss): 65 Section (__TEXT, __textcoal_nt): 116324 | Section (__TEXT, __textcoal_nt): 168920 Section (__TEXT, __literal8): 8 | Section (__TEXT, __eh_frame): 88636 Section (__TEXT, __StaticInit): 147 | Section (__TEXT, __StaticInit): 166 Section (__IMPORT, __jump_table): 12790 | Section (__IMPORT, __jump_table): 12410 Section (__IMPORT, __pointers): 136 | Section (__IMPORT, __pointers): 128 total 1495929 | total 2211...

...7fc4230f4e00).__TEXT > 0x00000001 code [0x0000000112f5f1c0-0x0000000112f5f8fb) 0x000003b0 0x0000073b 0x80000400 JIT(0x7fc4230f4e00).__TEXT.__text > 0x00000009 eh-frame [0x0000000112efccf8-0x0000000112efcd68) 0x00000c90 0x00000070 0x6800000b JIT(0x7fc4230f4e00).__TEXT.__eh_frame > 0x00000200 container [0x0000000000000784-0x0000000112efce75)* 0x00000aeb 0x00000160 0x00000000 JIT(0x7fc4230f4e00).__DWARF > 0x00000002 dwarf-info [0x0000000112efcd68-0x0000000112efcdb1) 0x00000aeb 0x00000049 0x02000000 JIT(0x7fc4230f4e00).__DWARF.__debug_info > 0x000...

On Mon, 28 Aug 2006, Jing Yu wrote: I don't really have any ideas beyond what Reid has already said, but: > pollux:~/test jingyu$ opt -load > /Users/jingyu/tools/build-ppc/Release/lib/LLVMHello.so -help > Error opening '/Users/jingyu/tools/build-ppc/Release/lib/LLVMHello.so': > Can't open :/Users/jingyu/tools/build-ppc/Release/lib/LLVMHello.so: >

...this: .section __DATA,__gcc_except_tab .align 2 GCC_except_table13: .byte 0x0 #< --- hun? .byte 0x0 #< --- hun? Lexception13: .byte 0xFF .byte 0x0 .byte 0xB2, 0x1 > Here are his comments: The problem is that the linker parses FDE which gives it all the LSDA starts. The __eh_frame and __gcc_except_tab sections should not need any labels, since the structure in them is self describing. But with this padding, the LSDA starts from the FDEs and the GCC_except_table* labels are now different. It looks like your goal is to keep the 32-bit pointers in the call-site table 4-byte al...

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

Thank you, Reid. I have applied tha patch to ltdl.c ltdl.h. The problem still exists. I looked up the symbol on libLLVMCore.a, and found three U-entries and one T-entry. However, the Darwin linker is not able to find the T-entry. Any idea? pollux:~/test jingyu$ opt -load /Users/jingyu/tools/build-ppc/Release/lib/LLVMHello.so -help Error opening

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

We are trying to switch to the new orc v2 lljit engine at my work with hopes of parallel jitting. We are switching from the ExecutionEngine w/ OrcMCJitReplacement. We are having a hard time with global variables. We have found a way to create/emit new globals during jitting by using the old ExecutionEngine::getOrEmitGlobalVariable. Is there an easier way to do this with the new jit engine? We were

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

...             descriptor encoding. 4       DWARF        The frame, for whatever reason, cannot be adequately described using the         escape       compact unwind frame description. The remaining 24-bits are an index into                      what the DWARF standard calls the .debug_frame section (__eh_frame in                      LLVM). 2.2.1  RBP-based Frame (MODE=1) For a RBP-based frame, the remaining 24 bits are encoded as follows: | 23        16 | 15 | 14                                          0 | |-------------------------------------------------------------------| | OFFSET       | 0  | REG...

...ng. > 4 DWARF The frame, for whatever reason, cannot be > adequately described using the > escape compact unwind frame description. The remaining > 24-bits are an index into > what the DWARF standard calls the .debug_frame > section (__eh_frame in > LLVM). > > 2.2.1 RBP-based Frame (MODE=1) > For a RBP-based frame, the remaining 24 bits are encoded as follows: > > | 23 16 | 15 | 14 0 | > |-----------------------------------------------------------...

...The frame, for whatever reason, cannot be > > adequately described using the > > escape compact unwind frame description. The remaining > > 24-bits are an index into > > what the DWARF standard calls the .debug_frame > > section (__eh_frame in > > LLVM). > > > > 2.2.1 RBP-based Frame (MODE=1) > > For a RBP-based frame, the remaining 24 bits are encoded as follows: > > > > | 23 16 | 15 | 14 0 | > > |--------------------------...

...ding. > 4 DWARF The frame, for whatever reason, cannot be > adequately described using the > escape compact unwind frame description. The remaining > 24-bits are an index into > what the DWARF standard calls the .debug_frame > section (__eh_frame in > LLVM). > > 2.2.1 RBP-based Frame (MODE=1) > For a RBP-based frame, the remaining 24 bits are encoded as follows: > > | 23 16 | 15 | 14 0 | > |------------------------------------------------------------...