search for: cfi_sect

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...

...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...

...%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...

...y first encounter with > clang/llvm's internals, I'm not sure how to go about making the change. > Could someone give me some pointers? Is this something that InstAlias > can handle? > > An alternative workaround would be to just use gas as-is, but it gets > upset by the .cfi_section directives that clang emits. Is there some > way to suppress those (while keeping the rest of the cfi directives that > this version of gas does understand)? > > Thanks, > J > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://list...

...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...

...defined, but since this is my first encounter with clang/llvm's internals, I'm not sure how to go about making the change. Could someone give me some pointers? Is this something that InstAlias can handle? An alternative workaround would be to just use gas as-is, but it gets upset by the .cfi_section directives that clang emits. Is there some way to suppress those (while keeping the rest of the cfi directives that this version of gas does understand)? Thanks, J

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 th...

...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 # Offse...

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;