search for: extab

Displaying 7 results from an estimated 7 matches for "extab".

Did you mean: xtab
2017 Mar 21
4
Resurrect Bug18710 (Only generate .ARM.exidx and ARM.extab when needed with EHABI)
...ay of posting 2 related or dependent patches ? - I'd like to update and follow on the discussion on bugzilla tracker that Renato created already but I can't edit (account requested to llvm-admin at lists.llvm.org without luck). Could someone help ? So now the proposal: The .exidx and .extab unwind sections are needed, when exceptions are enabled, for unwinding if the function can throw and to hold the EXIDX_CANTUNWIND value if the function does not throw. The problem was already discussed in various threads and defects, so I won't repeat the details but basically that confusi...
2018 Jan 06
2
LLVM EH tables much larger than GCC's
Hi, I'm investigating the size of Clang's generated binaries relative to GCC, when targeting Android, and I've noticed that Clang's exception tables are much larger -- the .ARM.extab section is about 2.5 times as large in two examples. I noticed a couple of differences between Clang and GCC: 1. *ULEB128 encoding.* In the call site table, GCC encodes offsets using a ULEB128 variable-length encoding, whereas LLVM uses fixed-size 32-bit values (udata4). Switching to ULEB128 is...
2018 Jan 10
0
LLVM EH tables much larger than GCC's
...es a landing pad that calls __clang_call_terminate to > terminate the program. GCC instead leaves a gap in the call site table, > and the personality routine calls std::terminate. For the 4MB > libQt5Core.so sample I'm looking at, I think it'd reduce the size of .text > and .ARM.extab by maybe 7000 bytes (about 0.18%). (I see about 500 calls to > __clang_call_terminate, and I estimate 14 bytes per call, assuming the call > site table is using ULEB128 already.) > > I tried to implement this in LLVM, but couldn't find a good way to > represent the calls that mus...
2012 Oct 22
0
[LLVMdev] Does someone still keep eye on MC ARM EHABI?
Hello > My question is, to avoid duplicate effort, > does someone take charge of this part? or > does anyone is already implementing this currently? > > BTW, any suggestion on this effort? I'm very appreciated! There are several directions here: 1. Binary emission. Right now MC layer is text-only and depends on assembler 2. Correctness issues. It's believed that unwinding
2012 Oct 22
1
[LLVMdev] Does someone still keep eye on MC ARM EHABI?
...hose references are very helpful! BTW, After I applying this patch from Logan Chien, I pass some examples on ARM assembly emission. It seems good to me. http://llvm.org/bugs/show_bug.cgi?id=7187#attach_9161 For object file emission, The first thing is making MC generate correct .ARM.exidx and .ARM.extab. I will keep tracing that. Thanks! 2012/10/22 Anton Korobeynikov <anton at korobeynikov.info> > Hello > > > My question is, to avoid duplicate effort, > > does someone take charge of this part? or > > does anyone is already implementing this currently? > > &gt...
2018 Jan 11
1
LLVM EH tables much larger than GCC's
...that calls __clang_call_terminate to >> terminate the program. GCC instead leaves a gap in the call site table, >> and the personality routine calls std::terminate. For the 4MB >> libQt5Core.so sample I'm looking at, I think it'd reduce the size of .text >> and .ARM.extab by maybe 7000 bytes (about 0.18%). (I see about 500 calls to >> __clang_call_terminate, and I estimate 14 bytes per call, assuming the call >> site table is using ULEB128 already.) >> >> I tried to implement this in LLVM, but couldn't find a good way to >> represen...
2012 Oct 22
3
[LLVMdev] Does someone still keep eye on MC ARM EHABI?
Dear all, AFAIK, ARM EHABI is not ready for both asm and obj emitter. Some people including me what to implement them. My question is, to avoid duplicate effort, does someone take charge of this part? or does anyone is already implementing this currently? BTW, any suggestion on this effort? I'm very appreciated! Thanks in advance! -- Best regards, Wen-Han Gu (Nowar) -------------- next