-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Debug info generation (LLVM-56) #6
Comments
So I actually logged the entire build process when not building with debug info, and before the relocation errors I actually get CFI not supported errors, here's the full log. Seems like rustc is inject CFI directives into the asm. |
I don't its specific to Rust (nor an issue with frame pointers for that matter), I think its specific to llvm. Adapting the simple clang example to include debug info test.S: Assembler messages:
test.S:10: Error: CFI is not supported for this target
test.S:11: Error: CFI is not supported for this target
test.S:13: Error: CFI is not supported for this target
test.S:23: Error: CFI is not supported for this target
test.S: Error: unhandled local relocation fix BFD_RELOC_64
test.S: Error: unhandled local relocation fix BFD_RELOC_64 test.c:
test.S: .text
.file "test.c"
.global main
.p2align 2
.type main,@function
main:
Lfunc_begin0:
.file 1 "test.c"
.loc 1 3 0
.cfi_sections .debug_frame
.cfi_startproc
entry sp, 40
.cfi_def_cfa_offset 40
movi.n a8, 0
s32i.n a8, sp, 0
Ltmp0:
.loc 1 4 2 prologue_end
mov.n a2, a8
retw.n
Ltmp1:
Lfunc_end0:
.size main, Lfunc_end0-main
.cfi_endproc
.section .debug_str,"MS",@progbits,1
Linfo_string0:
.asciz "clang version 6.0.1 (https://github.com/espressif/clang-xtensa.git 6fb488d2553f06029e6611cf81c6efbd45b56e47) (https://github.com/espressif/llvm-xtensa.git 757e18f722dbdcd98b8479e25041b1eee1128ce9)"
Linfo_string1:
.asciz "test.c"
Linfo_string2:
.asciz "/home/mabez/development/rust/rust-xtensa/llvm_build/bin"
Linfo_string3:
.asciz "main"
Linfo_string4:
.asciz "int"
.section .debug_abbrev,"",@progbits
.byte 1
.byte 17
.byte 1
.byte 37
.byte 14
.byte 19
.byte 5
.byte 3
.byte 14
.byte 16
.byte 23
.byte 27
.byte 14
.ascii "\264B"
.byte 25
.byte 17
.byte 1
.byte 18
.byte 6
.byte 0
.byte 0
.byte 2
.byte 46
.byte 0
.byte 17
.byte 1
.byte 18
.byte 6
.byte 64
.byte 24
.byte 3
.byte 14
.byte 58
.byte 11
.byte 59
.byte 11
.byte 73
.byte 19
.byte 63
.byte 25
.byte 0
.byte 0
.byte 3
.byte 36
.byte 0
.byte 3
.byte 14
.byte 62
.byte 11
.byte 11
.byte 11
.byte 0
.byte 0
.byte 0
.section .debug_info,"",@progbits
Lcu_begin0:
.long 71
.short 4
.long .debug_abbrev
.byte 8
.byte 1
.long Linfo_string0
.short 12
.long Linfo_string1
.long Lline_table_start0
.long Linfo_string2
.quad Lfunc_begin0
.long Lfunc_end0-Lfunc_begin0
.byte 2
.quad Lfunc_begin0
.long Lfunc_end0-Lfunc_begin0
.byte 1
.byte 81
.long Linfo_string3
.byte 1
.byte 3
.long 67
.byte 3
.long Linfo_string4
.byte 5
.byte 4
.byte 0
.section .debug_ranges,"",@progbits
.section .debug_macinfo,"",@progbits
Lcu_macro_begin0:
.byte 0
.section .debug_pubnames,"",@progbits
.long LpubNames_end0-LpubNames_begin0
LpubNames_begin0:
.short 2
.long Lcu_begin0
.long 75
.long 42
.asciz "main"
.long 0
LpubNames_end0:
.section .debug_pubtypes,"",@progbits
.long LpubTypes_end0-LpubTypes_begin0
LpubTypes_begin0:
.short 2
.long Lcu_begin0
.long 75
.long 67
.asciz "int"
.long 0
LpubTypes_end0:
.section .debug_line,"",@progbits
Lline_table_start0: |
.file "test.c"
.text
.Ltext0:
.align 4
.global main
.type main, @function
main:
.LFB0:
.file 1 "test.c"
.loc 1 4 1
entry sp, 32
mov.n a7, sp
.LCFI0:
.loc 1 5 12
movi.n a2, 0
.loc 1 6 1
retw.n
.LFE0:
.size main, .-main
.section .debug_frame,"",@progbits
.Lframe0:
.4byte .LECIE0-.LSCIE0
.LSCIE0:
.4byte 0xffffffff
.byte 0x3
.string ""
.uleb128 0x1
.sleb128 -4
.uleb128 0
.byte 0xc
.uleb128 0x1
.uleb128 0
.align 4
.LECIE0:
.LSFDE0:
.4byte .LEFDE0-.LASFDE0
.LASFDE0:
.4byte .Lframe0
.4byte .LFB0
.4byte .LFE0-.LFB0
.byte 0x4
.4byte .LCFI0-.LFB0
.byte 0xc
.uleb128 0x7
.uleb128 0x20
.align 4
.LEFDE0:
.text
.Letext0:
.section .debug_info,"",@progbits
.Ldebug_info0:
.4byte 0x3f
.2byte 0x4
.4byte .Ldebug_abbrev0
.byte 0x4
.uleb128 0x1
.4byte .LASF0
.byte 0xc
.4byte .LASF1
.4byte .LASF2
.4byte .Ltext0
.4byte .Letext0-.Ltext0
.4byte .Ldebug_line0
.uleb128 0x2
.4byte .LASF3
.byte 0x1
.byte 0x3
.byte 0x5
.4byte 0x3b
.4byte .LFB0
.4byte .LFE0-.LFB0
.uleb128 0x1
.byte 0x9c
.uleb128 0x3
.byte 0x4
.byte 0x5
.string "int"
.byte 0
.section .debug_abbrev,"",@progbits
.Ldebug_abbrev0:
.uleb128 0x1
.uleb128 0x11
.byte 0x1
.uleb128 0x25
.uleb128 0xe
.uleb128 0x13
.uleb128 0xb
.uleb128 0x3
.uleb128 0xe
.uleb128 0x1b
.uleb128 0xe
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x6
.uleb128 0x10
.uleb128 0x17
.byte 0
.byte 0
.uleb128 0x2
.uleb128 0x2e
.byte 0
.uleb128 0x3f
.uleb128 0x19
.uleb128 0x3
.uleb128 0xe
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x39
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x6
.uleb128 0x40
.uleb128 0x18
.uleb128 0x2117
.uleb128 0x19
.byte 0
.byte 0
.uleb128 0x3
.uleb128 0x24
.byte 0
.uleb128 0xb
.uleb128 0xb
.uleb128 0x3e
.uleb128 0xb
.uleb128 0x3
.uleb128 0x8
.byte 0
.byte 0
.byte 0
.section .debug_aranges,"",@progbits
.4byte 0x1c
.2byte 0x2
.4byte .Ldebug_info0
.byte 0x4
.byte 0
.2byte 0
.2byte 0
.4byte .Ltext0
.4byte .Letext0-.Ltext0
.4byte 0
.4byte 0
.section .debug_line,"",@progbits
.Ldebug_line0:
.section .debug_str,"MS",@progbits,1
.LASF2:
.string "/home/mabez/development/c/blink"
.LASF1:
.string "test.c"
.LASF0:
.string "GNU C17 8.2.0 -g"
.LASF3:
.string "main"
.ident "GCC: (crosstool-NG esp32-2019r1) 8.2.0"
Which doesn't include any CFI directive, just dwarf debug_* sections. |
So after investigating, this actually seems to be two separate issues, firstly the cfi issue. Which can be manually neutralized by using this Secondly the
Which I have no idea how to solve. Here is the CFI-less asm file incase you need it: .text
.file "test.c"
.global main
.p2align 2
.type main,@function
main:
Lfunc_begin0:
.file 1 "test.c"
.loc 1 3 0
entry sp, 40
movi.n a8, 0
s32i.n a8, sp, 0
Ltmp0:
.loc 1 4 2 prologue_end
mov.n a2, a8
retw.n
Ltmp1:
Lfunc_end0:
.size main, Lfunc_end0-main
.section .debug_str,"MS",@progbits,1
Linfo_string0:
.asciz "clang version 6.0.1 (https://github.com/espressif/clang-xtensa.git 6fb488d2553f06029e6611cf81c6efbd45b56e47) (https://github.com/espressif/llvm-xtensa.git 757e18f722dbdcd98b8479e25041b1eee1128ce9)"
Linfo_string1:
.asciz "test.c"
Linfo_string2:
.asciz "/home/mabez/development/rust/rust-xtensa/llvm_build/bin"
Linfo_string3:
.asciz "main"
Linfo_string4:
.asciz "int"
.section .debug_abbrev,"",@progbits
.byte 1
.byte 17
.byte 1
.byte 37
.byte 14
.byte 19
.byte 5
.byte 3
.byte 14
.byte 16
.byte 23
.byte 27
.byte 14
.ascii "\264B"
.byte 25
.byte 17
.byte 1
.byte 18
.byte 6
.byte 0
.byte 0
.byte 2
.byte 46
.byte 0
.byte 17
.byte 1
.byte 18
.byte 6
.byte 64
.byte 24
.byte 3
.byte 14
.byte 58
.byte 11
.byte 59
.byte 11
.byte 73
.byte 19
.byte 63
.byte 25
.byte 0
.byte 0
.byte 3
.byte 36
.byte 0
.byte 3
.byte 14
.byte 62
.byte 11
.byte 11
.byte 11
.byte 0
.byte 0
.byte 0
.section .debug_info,"",@progbits
Lcu_begin0:
.long 71
.short 4
.long .debug_abbrev
.byte 8
.byte 1
.long Linfo_string0
.short 12
.long Linfo_string1
.long Lline_table_start0
.long Linfo_string2
.quad Lfunc_begin0
.long Lfunc_end0-Lfunc_begin0
.byte 2
.quad Lfunc_begin0
.long Lfunc_end0-Lfunc_begin0
.byte 1
.byte 81
.long Linfo_string3
.byte 1
.byte 3
.long 67
.byte 3
.long Linfo_string4
.byte 5
.byte 4
.byte 0
.section .debug_ranges,"",@progbits
.section .debug_macinfo,"",@progbits
Lcu_macro_begin0:
.byte 0
.section .debug_pubnames,"",@progbits
.long LpubNames_end0-LpubNames_begin0
LpubNames_begin0:
.short 2
.long Lcu_begin0
.long 75
.long 42
.asciz "main"
.long 0
LpubNames_end0:
.section .debug_pubtypes,"",@progbits
.long LpubTypes_end0-LpubTypes_begin0
LpubTypes_begin0:
.short 2
.long Lcu_begin0
.long 75
.long 67
.asciz "int"
.long 0
LpubTypes_end0:
.section .debug_line,"",@progbits
Lline_table_start0:
|
Hello @MabezDev ! Thank you for your investigation. We continue to develop Xtensa LLVM backend and we will also use your results to improve it. Soon we will update Xtensa LLVM/Clang forks. |
@andreisfr No problem! Hopefully its useful information. Let me know if there is anything else you'd like me to try. I look forward to trying out the updates! |
This patch re-introduces the fix in the commit llvm@66b0cebf7f736 by @yrnkrn > In DwarfEHPrepare, after all passes are run, RewindFunction may be a dangling > > pointer to a dead function. To make sure it's valid, doFinalization nullptrs > RewindFunction just like the constructor and so it will be found on next run. > > llvm-svn: 217737 It seems that the fix was not migrated to `DwarfEHPrepareLegacyPass`. This patch also updates `llvm/test/CodeGen/X86/dwarf-eh-prepare.ll` to include `-run-twice` to exercise the cleanup. Without this patch `llvm-lit -v llvm/test/CodeGen/X86/dwarf-eh-prepare.ll` fails with ``` -- Testing: 1 tests, 1 workers -- FAIL: LLVM :: CodeGen/X86/dwarf-eh-prepare.ll (1 of 1) ******************** TEST 'LLVM :: CodeGen/X86/dwarf-eh-prepare.ll' FAILED ******************** Script: -- : 'RUN: at line 1'; /home/arakaki/build/llvm-project/main/bin/opt -mtriple=x86_64-linux-gnu -dwarfehprepare -simplifycfg-require-and-preserve-domtree=1 -run-twice < /home/arakaki/repos/watch/llvm-project/llvm/test/CodeGen/X86/dwarf-eh-prepare.ll -S | /home/arakaki/build/llvm-project/main/bin/FileCheck /home/arakaki/repos/watch/llvm-project/llvm/test/CodeGen/X86/dwarf-eh-prepare.ll -- Exit Code: 2 Command Output (stderr): -- Referencing function in another module! call void @_Unwind_Resume(i8* %ehptr) #1 ; ModuleID = '<stdin>' void (i8*)* @_Unwind_Resume ; ModuleID = '<stdin>' in function simple_cleanup_catch LLVM ERROR: Broken function found, compilation aborted! PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: /home/arakaki/build/llvm-project/main/bin/opt -mtriple=x86_64-linux-gnu -dwarfehprepare -simplifycfg-require-and-preserve-domtree=1 -run-twice -S 1. Running pass 'Function Pass Manager' on module '<stdin>'. 2. Running pass 'Module Verifier' on function '@simple_cleanup_catch' #0 0x000056121b570a2c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/arakaki/repos/watch/llvm-project/llvm/lib/Support/Unix/Signals.inc:569:0 #1 0x000056121b56eb64 llvm::sys::RunSignalHandlers() /home/arakaki/repos/watch/llvm-project/llvm/lib/Support/Signals.cpp:97:0 #2 0x000056121b56f28e SignalHandler(int) /home/arakaki/repos/watch/llvm-project/llvm/lib/Support/Unix/Signals.inc:397:0 #3 0x00007fc7e9b22980 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12980) #4 0x00007fc7e87d3fb7 raise /build/glibc-S7xCS9/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0 #5 0x00007fc7e87d5921 abort /build/glibc-S7xCS9/glibc-2.27/stdlib/abort.c:81:0 #6 0x000056121b4e1386 llvm::raw_svector_ostream::raw_svector_ostream(llvm::SmallVectorImpl<char>&) /home/arakaki/repos/watch/llvm-project/llvm/include/llvm/Support/raw_ostream.h:674:0 #7 0x000056121b4e1386 llvm::report_fatal_error(llvm::Twine const&, bool) /home/arakaki/repos/watch/llvm-project/llvm/lib/Support/ErrorHandling.cpp:114:0 #8 0x000056121b4e1528 (/home/arakaki/build/llvm-project/main/bin/opt+0x29e3528) #9 0x000056121adfd03f llvm::raw_ostream::operator<<(llvm::StringRef) /home/arakaki/repos/watch/llvm-project/llvm/include/llvm/Support/raw_ostream.h:218:0 FileCheck error: '<stdin>' is empty. FileCheck command line: /home/arakaki/build/llvm-project/main/bin/FileCheck /home/arakaki/repos/watch/llvm-project/llvm/test/CodeGen/X86/dwarf-eh-prepare.ll -- ******************** ******************** Failed Tests (1): LLVM :: CodeGen/X86/dwarf-eh-prepare.ll Testing Time: 0.22s Failed: 1 ``` Reviewed By: loladiro Differential Revision: https://reviews.llvm.org/D110979 (cherry picked from commit e8806d7)
I've recently been motivated to get back on the horse and continue trying to make Rust viable with this fork. I've managed to replace with esp bootloader with a pure Rust one, that simply calls a main function and loops forever.
I've hit a stumbling block, unfortunately Rust requires frame pointers to generate debug info. So far to verify my programs is working I have been stepping through and matching the current pc with a objdump of the binary, this works to prove the chip is running my code but It's not viable to do any further development.
Is something blocking frame-pointers from being supported?
The text was updated successfully, but these errors were encountered: