Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Debug info generation (LLVM-56) #6

Closed
MabezDev opened this issue Aug 22, 2019 · 6 comments
Closed

Debug info generation (LLVM-56) #6

MabezDev opened this issue Aug 22, 2019 · 6 comments

Comments

@MabezDev
Copy link

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
Copy link
Author

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
Copy link
Author

MabezDev commented Aug 27, 2019 •
edited

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
Copy link
Author

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
Copy link
Author

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:

@MabezDev MabezDev changed the title Support for frame pointers Debug info generation Aug 27, 2019
@andreisfr
Copy link
Collaborator

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
Copy link
Author

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

@igrr igrr transferred this issue from espressif/llvm-xtensa Jan 15, 2020
@MabezDev MabezDev mentioned this issue Jan 18, 2020
Closed
@espressif-bot espressif-bot changed the title Debug info generation Debug info generation (LLVM-56) Jan 29, 2020
@MabezDev MabezDev closed this as completed Feb 3, 2020
@Abdillah Abdillah mentioned this issue Apr 10, 2020
Closed
igrr pushed a commit that referenced this issue Dec 3, 2021
@tkf @tstellar
Re-apply the fix on DwarfEHPrepare and add a test
d218ef0 
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@MabezDev @andreisfr