This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Need help with gas directive .cfi_sections
- From: Sharyathi Nagesh <sharyath at in dot ibm dot com>
- To: binutils at sourceware dot org, jakub at redhat dot com, ", schwab at redhat dot com"@d28av01.in.ibm.com
- Cc: Mohan Kumar M <mohan at in dot ibm dot com>
- Date: Thu, 19 Nov 2009 20:36:39 +0530
- Subject: Need help with gas directive .cfi_sections
Hi
We need some help and guidance with some issues we are facing. We are exploring option to
unwind through linux kernel dumps using dwarf information. Major challenge we are facing is
with respect to unwinding through the exception framework. Even through exception handler
code has gas directive to emit debug information (x86 & x86_64) by default it works only
with .eh_frame. Earlier we had observed that relying on eh_frame to unwind is not reliable
and hence we are exploring .debug_frame.
So as I understand in October a patch was provided to implement .cfi_sections directive
which will help to emit dwarf information in .debug_frame. I tested this with latest
binutils from cvs.
We need clarification on these issues
1. We wanted to know from which version of GCC can we expect to see .cfi_section directive.
I need this information, so that I can modify code in entry_32.S code in linux kernel to
some thing like this
#if GCC_VERSION > 4.5 (say)
#define CFI_SECTIONS .cfi_sections
#else
#define CFI_SECTIONS NULL
#endif
Any suggestions on when it will be part of GCC and what will be the best way to code without
braking the compatibility will be greatly helpful
---------------------------------------------------------------------------------------------
2. We tried generating .debug_frame information with the latest binutils tools and We saw
some anomalies. We wanted to confirm if it is due to usage issues,of gas or assembly code,
or there is indeed some issues with the .cfi_sections patch
This is what we did (Under PPC64 arch)
We assembled this code:
--------------------
test.s:
.global test1
test1:
.cfi_startproc
.cfi_signal_frame
.cfi_sections .debug_frame
.cfi_def_cfa_offset 8
.cfi_def_cfa r3, 4
.cfi_endproc
mr 10,9
blr
--------------------
assemble using as from the latest binutils
./as test.s
--------------------
This is the dwarf .debug_frame information that we got
00000060 00000014 ffffffff CIE
Version: 1
Augmentation: ""
Code alignment factor: 4
Data alignment factor: -8
Return address column: 65
DW_CFA_def_cfa: r1 ofs 0
DW_CFA_def_cfa_offset: 8
DW_CFA_def_cfa: r3 ofs 4
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
00000078 00000014 00000060 FDE cie=00000060 pc=00000000..00000000
We were concerned with the address range of the FDE, both low_pc and high_pc both are
00000000. So why is it shown like that? Should not it be range of virtual address where this
text segment will be loaded in memory ?
We had this query as unwinding without proper range will become difficult
So please do let me know your thoughts, It will help us greatly
Thanks
Sharyathi N