search for: cfi_sections

Hi, :If I compile this file with debugging enabled (clang/LLVM TOT) int main() { } I get the error Error: inconsistent uses of .cfi_sections From the 2.27 binutils assemblers. It seems that 2.27 doesn't like the .cfi_sections .debug_frame directive following previous .cfi directives. The assemblers seem to be happy if the .cfi_sections directive precedes any other .cfi directive. Is this a bug in binutils or LLVM? It looks as...

...if (!F.isDeclarationForLinker() && F.needsUnwindTableEntry()) {// //*isCFIMoveForDebugging = false;*// // break;// // }// / The ExceptionHandlingType for AArch64 is ExceptionHandling::DwarfCFI whereas for ARM it is ExceptionHandling::ARM. As a result, the behavior of the .cfi_sections differs for ARM vs AArch64. Due to this, my test which checks for .cfi_sections and .debug_frame passes for ARM but fails for AArch64. Could you please clarify, why the behavior for handling .cfi_sections needs to be different between ARM and AArch64? --Mandeep -------------- next part -----...

...%t %s && %ppc64run %t // RUN: %x86_64ecc -g -o %t %s && %x86_64run %t int comm; int main() { comm = 6; } This fails on all but the x86 processors. The typical failure looks like this: ... .type comm, at object # @comm .comm comm,4,4 .cfi_sections .debug_frame .bss .L.bss_end: ... .L.debug_abbrev_end: .section .debug_aranges,"", at progbits .long 36 # Length of ARange Set .short 2 # DWARF Arange version number .long .L.debug_info_beg...

...%s && %x86_64run %t > > int comm; > int main() > { > comm = 6; > } > > This fails on all but the x86 processors. The typical failure looks like > this: > ... > .type comm, at object # @comm > .comm comm,4,4 > .cfi_sections .debug_frame > .bss > .L.bss_end: > ... > .L.debug_abbrev_end: > .section .debug_aranges,"", at progbits > .long 36 # Length of ARange Set > .short 2 # DWARF Arange version number &gt...

Jeremy, Could you send/attach a small test case that demonstrates the problem? It doesn't need to go past the stage that creates a .o. Also, what version of gnu as are you using? Unless it conflicts with a fundamental llvm/clang philosophy, we are trying to keep Mips assembly compatible with AS. Also, keep in mind that the Mips llvm assembler is current development and is not considered

...s && %x86_64run %t > > int comm; > int main() > { > comm = 6; > } > > This fails on all but the x86 processors. The typical failure looks > like this: > ... > .type comm, at object # @comm > .comm comm,4,4 > .cfi_sections .debug_frame > .bss > .L.bss_end: > ... > .L.debug_abbrev_end: > .section .debug_aranges,"", at progbits > .long 36 # Length of ARange Set > .short 2 # DWARF Arange version number &gt...

Hi all, I'm experimenting with compiling some Mips code which is normally built with a gcc cross toolchain with clang instead. This code targets the Cavium Octeon, and uses some of that CPU's crypto engine features which are implemented in coprocessor 2. The inline asm for the crypto code uses instructions of the form "dmtc2 %0, 0xNNNN" - that is the coprocessor register is

Thanks for reducing that for me! The outliner pulls out the following: OUTLINED_FUNCTION_0: // @OUTLINED_FUNCTION_0 .cfi_sections .debug_frame .cfi_startproc // %bb.0: adrp x29, g1 add x29, x29, :lo12:g1 adrp x30, g2 // This adrp shouldn’t have been outlined. ret It shouldn’t be pulling out that adrp. There’s a special case for arps in the outliner which hinged on the assumption that x...

...hing_different, 4 .type .L.str, at object # @.str .section .rodata.str1.1,"aMS", at progbits,1 .L.str: .asciz "made it to moo %d\n" .size .L.str, 19 .type .L.str1, at object # @.str1 .L.str1: .asciz "made it to meh %d\n" .size .L.str1, 19 .cfi_sections .debug_frame .text .Ltext_end: .data .Ldata_end: .text .Lsection_end1: .section .debug_info,"", at progbits .Linfo_begin1: .long 311 # Length of Compilation Unit Info .short 2 # DWARF version number .long .Labbrev_begin # Offset In...

Sorry, I was using a modified compiler, which by coincidence made the bug much easier to reproduce. In some rare cases, the compiler will use x30 as a general-purpose register; in that case, outlining breaks because the "ret" branches to the wrong address.  Testcase (reproduce with "clang -O3 --target=aarch64-pc-linux-gnu -mllvm -enable-machine-outliner"): extern long g1;