Re: [Open64-devel] .eh_frame section for C
Brought to you by:
ributzka,
suneeljain
Menu
▾
▴
Re: [Open64-devel] .eh_frame section for C
|
From: Gautam C. <gau...@ya...> - 2010-05-22 22:59:14
|
It probably is ok to generate .debug_frame instead of .eh_frame for C (we already generate .debug_frame under -g). Regarding compatibility with GCC, Suneel and I had some offline conversation. It appears different versions of GCC has different conventions. Some versions of GCC including 4.4.0 generate .eh_frame for C by default. Some other versions including their latest version 4.5.0 do not generate any frame by default, and generate only .debug_frame under -g. So GCC 4.5.0 will not support stack backtrace by default. If open64 always generates the debug frame, it may have a performance effect in some cases. Gautam ________________________________ From: Sun Chan <sun...@gm...> To: Hucheng Zhou <zho...@gm...> Cc: Gautam Chakrabarti <gau...@ya...>; ope...@li... Sent: Fri, May 21, 2010 7:58:38 PM Subject: Re: [Open64-devel] .eh_frame section for C I agree with that. In a lot of apps such as Oracle requires that one always can walk the frame for debugging, .debug_frame is a much more appropriate way to go Sun On Sat, May 22, 2010 at 9:58 AM, Hucheng Zhou <zho...@gm...> wrote: For C, can we generate .debug_frame section, rather than .eh_frame? >FDE and CIE information can be located at .debug_frame section. > > > >On Sat, May 22, 2010 at 12:30 AM, Gautam Chakrabarti <gau...@ya...> wrote: > >I agree that in general .eh_frame is needed for C++ exception handling. But there are certain circumstances when it's required for C also. I vaguely remember a requirement that we needed to be able to generate backtraces even without -g, which would justify its presence below. The CIE can pretty much be the same irrespective of the code you have. But if I remember correctly, it's useless without the FDEs for each function, and the FDEs are missing below. Backtrace cannot work without the FDEs. So either the implementation of DEBUG_Emit_Ehframe broke at some point, and we need to enable emitting FDEs by default, or we can stop emitting the CIE by default. In that case at -g, we will generate the correct .eh_frame with CIE and FDEs. >> >>Always generating the CIE and the whole chain of FDEs by default does not look very good to me, unless we are aware of a specific requirement. So probably -DEBUG:eh_frame should be disabled by default. >> >>Gautam >> >> >> >> ________________________________ From: Richard D. Li <li...@gm...> >>To: Hucheng Zhou <zho...@gm...> >>Cc: ope...@li... >>Sent: Fri, May 21, 2010 3:50:22 AM >>Subject: Re: [Open64-devel] .eh_frame section for C >> >> >>So it puzzles me that there is an option "-DEBUG:eh_frame" and it is on >>by default even without "-g". >> >>If C does not need .eh_frame section, and this option does not affect >>C++ (it is always used like this: if(is_cplus || DEBUG_Emit_Ehframe)), >>it means that this option is not so useful, or at least it should be >>off if "-g" is not set. Is that right? >> >>Thanks. >> >>On 05/21/2010 05:17 PM, Hucheng Zhou wrote: >>> I think C language don't need .eh_frame section, without EH features. >>> >>> >>> >>> On Fri, May 21, 2010 at 5:09 PM, Richard D. Li <li...@gm... >>> <mailto:li...@gm...>> wrote: >>> >>> Hi, >>> >>> I noticed the .eh_frame section generated by open64 is identical for any >>> C source file, even if the file is empty. It always contains only one >>> CIE block and nothing else (on a x86 system; tried most recent svn >>> revision and 4.2.1): >>> >>> .section .eh_frame, "a",@progbits >>> .LEHCIE: >>> .4byte .LEHCIE_end - .LEHCIE_begin >>> .LEHCIE_begin: >>> .4byte 0x0 >>> .byte 0x01, 0x00, 0x01, 0x7c, 0x08, 0x0c, 0x04, 0x04 >>> .byte 0x88, 0x01 >>> .align 4 >>> .LEHCIE_end: >>> >>> AFAIK, the .eh_frame section is mainly used by C++ exception handling. >>> It is also generated for C if "-DEBUG:eh_frame" is on (the default) - >>> the comment in open64 source says "emit .eh_frame for backtrace". >>> However, I wonder if the above section actually contains any useful info >>> - its size does not even grow as the number of functions increases. So I >>> assume this may be a bug? Thanks. >>> >>> >>> Richard >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Open64-devel mailing list >>> Ope...@li... >>> <mailto:Ope...@li...> >>> https://lists.sourceforge.net/lists/listinfo/open64-devel >>> >>> >>> >>> >>> -- >>> Institute of High Performance Computing, >>> >>> Department of Computer Science and Technology, >>> >>> Tsinghua University, Beijing, China, 100084. >> >> >>------------------------------------------------------------------------------ >> >>_______________________________________________ >>Open64-devel mailing list >>Ope...@li... >> >>https://lists.sourceforge.net/lists/listinfo/open64-devel >> >> > > >-- > >Institute of High Performance Computing, > >Department of Computer Science and Technology, > >Tsinghua University, Beijing, China, 100084. > >------------------------------------------------------------------------------ > > >_______________________________________________ >Open64-devel mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/open64-devel > > |