search

espressif / llvm-project

Fork of LLVM with Xtensa specific patches. To be upstreamed.
Other
234 stars 21 forks source link

Debug info generation (LLVM-56) #6

Closed MabezDev closed 4 years ago

MabezDev commented 5 years ago

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?

MabezDev commented 5 years ago

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.

MabezDev commented 5 years ago

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 clang -target xtensa -g -fomit-frame-pointer -S test.c -o test.S (Note the fp is still omitted) and this is the result when assembling the S file:

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:

int main() {
 return 0;
}

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:
MabezDev commented 5 years ago

xtensa-esp32-elf-gcc -S -g test.c on the same test.c file produces this:

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

MabezDev commented 5 years ago

So after investigating, this actually seems to be two separate issues, firstly the cfi issue. Which can be manually neutralized by using this .cfi_.*$\n regex to remove all the directives from the emitted asm.

Secondly the Error: unhandled local relocation fix BFD_RELOC_64 issue. Once the CFI directives are removed from the clang -target xtensa -g -fomit-frame-pointer -S test.c -o test.S generated file produces the following error when assembled:

/tmp/ccRW15DC.s: Assembler messages:
/tmp/ccRW15DC.s: Error: unhandled local relocation fix BFD_RELOC_64
/tmp/ccRW15DC.s: Error: unhandled local relocation fix BFD_RELOC_64

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:
andreisfr commented 5 years ago

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.

MabezDev commented 5 years ago

@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!