This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Sequel to PR40521 -- -g causes GCC to generate .eh_frame
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Thomas Schwinge <thomas at codesourcery dot com>
- Cc: Daniel Jacobowitz <dan at codesourcery dot com>, Jakub Jelinek <jakub at redhat dot com>, Ramana Radhakrishnan <ramana dot radhakrishnan at arm dot com>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 01 Apr 2010 13:26:02 +0100
- Subject: Re: Sequel to PR40521 -- -g causes GCC to generate .eh_frame
- References: <87ocic34pp.fsf@dirichlet.schwinge.homeip.net> <20100330145159.GA19009@caradoc.them.org> <87zl1o1oqe.fsf@dirichlet.schwinge.homeip.net>
On Wed, 2010-03-31 at 17:43 +0200, Thomas Schwinge wrote:
> Hello!
>
> On 2010-03-30 14:52, Daniel Jacobowitz wrote:
> > On Thu, Mar 25, 2010 at 02:34:26PM +0100, Thomas Schwinge wrote:
> >> Here is a sequel to PR40521 -- -g causes GCC to generate .eh_frame.
> >>
> >> On arm-none-linux-gnueabi, if -fexceptions /
> >> -fasynchronous-unwind-tables / -funwind-tables is in effect, GCC will
> >> now *always* emit CFI statements -- and .cfi_sections .debug_frame
> >> additionally *only* if -g is specified.
> >
> > This is IMO a serious problem; it generates a lot of extra data for
> > C++ on ARM (a primary platform).
>
>
> > I couldn't figure out the existing logic, so I've simplified it and
> > attached another possible solution (untested). It does have some
> > related changes in behavior, because the existing checks are
> > inconsistent; some are:
> >
> > flag_unwind_tables || (flag_exceptions && ! USING_SJLJ_EXCEPTIONS),
> >
> > Others are:
> >
> > ! USING_SJLJ_EXCEPTIONS && (flag_unwind_tables || flag_exceptions)
>
> I couldn't find anything obviously wrong with these simplifications.
>
>
> >> Defining gcc/config/arm/arm.h:DWARF2_UNWIND_INFO to 0 instead of 1 has
> >> the desired effect, but I'm not really sure that is correct to do?
> >
> > By comparison with IA64, I think this is (surprisingly, to me) the
> > right solution. In fact, delete the definition. Then non-EABI ARM
> > configurations will allow DWARF2_UNWIND_INFO via defaults.h.
>
> So, my original idea was not wrong, which is relieving.
>
> Deleting the definition is different from defining it to zero, as this is
> sort of a tri-state thing: undefined meaning that the DWARF unwinding
> machinery is not implemented, zero meaning that it is implemented but
> shall not be used, and one meaning that it shall be used. (See my
> documentation update, too.) For example, compare with this use in
> gcc/c-cppbuiltin.c:c_cpp_builtins:
>
> #ifdef DWARF2_UNWIND_INFO
> if (dwarf2out_do_cfi_asm ())
> cpp_define (pfile, "__GCC_HAVE_DWARF2_CFI_ASM");
> #endif
>
> I moved the to-zero definition to the place where TARGET_UNWIND_INFO is
> defined. Is that the correct place, or are there ARM configurations
> where this doesn't fit?
>
> > Thomas, want to give this a spin?
>
> Here is the patch that I've been testing to do the right thing for
> arm-none-linux-gnueabi, and not cause any regressions on
> i686-pc-linux-gnu. I used the following set of options...
>
> (none)
> -fno-dwarf2-cfi-asm
> -funwind-tables
> -fno-dwarf2-cfi-asm -funwind-tables
> -g
> -fno-dwarf2-cfi-asm -g
> -g -funwind-tables
> -fno-dwarf2-cfi-asm -g -funwind-tables
>
> ... on a simple C file containing a function that calls another external
> function, and inspected the generated assembler code as well as the
> object files for containing the correct statements, on i686-pc-linux-gnu
> and arm-none-linux-gnueabi.
>
> Automated regression testing on i686-pc-linux-gnu is still running. Any
> further testing needed?
>
> Is that patch OK? Who can approve it? Jakub can't, he said on IRC.
>
> gcc/
> 2010-03-31 Thomas Schwinge <thomas@codesourcery.com>
> Daniel Jacobowitz <dan@codesourcery.com>
>
> * doc/tm.texi (DWARF2_UNWIND_INFO, TARGET_UNWIND_INFO): Improve.
> * dwarf2out.c (NEED_UNWIND_TABLES): Define.
> (dwarf2out_do_frame, dwarf2out_do_cfi_asm, dwarf2out_begin_prologue)
> (dwarf2out_frame_finish, dwarf2out_assembly_start): Use it.
> (dwarf2out_assembly_start): Correct logic for TARGET_UNWIND_INFO.
> * config/arm/arm.h (DWARF2_UNWIND_INFO): Remove definition.
> * config/arm/bpabi.h (DWARF2_UNWIND_INFO): Define to zero.
> +Defining this macro will inhibit the default of generating DWARF 2 frame
> +debugging information, see @code{DWARF2_UNWIND_INFO}.
> @end defmac
I don't understand this bit. Firstly, I think you mean "unwind", not
"debugging". Secondly, if you mean that the setting of
DWARF2_UNWIND_INFO will be ignored, then I think it would be better to
say that.
R.