Bug 48459

Increased the importance from P3 to P3 because this makes avr-gcc+dwarf-2 completely unusable. 

Configuring as --target=avr --with-dwarf2 fails to build cross compiler.

Mike Stein's gcc-testresults indicate that avr+dwarf2 is already broken throughout 4.6 and works in 4.5.

(In reply to comment #1)
> Increased the importance from P3 to P3 because this makes avr-gcc+dwarf-2
> completely unusable. 
> 
> Configuring as --target=avr --with-dwarf2 fails to build cross compiler.

It fails with the message:

configure:3055: /home/anitha/comp/gcc-4.6.0/objdir/./gcc/xgcc -B/home/anitha/comp/gcc-4.6.0/objdir/./gcc/ -B/home/anitha/install/avr/bin/ -B/home/anitha/install/avr/lib/ -isystem /home/anitha/install/avr/include -isystem /home/anitha/install/avr/sys-include    -o conftest -O2 -g   conftest.c  >&5
conftest.c:1:0: internal compiler error: in dwarf2out_frame_init, at dwarf2out.c:4260


Further analysis shows that the changes introduced in revision 164701 (Found in Tag: gcc_4_6_0_release) cause ICE.

http://gcc.gnu.org/viewcvs/tags/gcc_4_6_0_release/gcc/dwarf2out.c?r1=164670&r2=164701&diff_format=h

The macros DWARF2_UNWIND_INFO is undefined for AVR Target and hence the initial_return_save() is neither defined nor called in 4.5.* versions. However in 4.6.0 these macros are replaced with 'targetm' hooks, which return UI_DWARF2 and hence the function initial_return_save() gets called. Since INCOMING_RETURN_ADDR_RTX is not defined, it results in ICE. (I have given the preprocessed output from dwarf2out_frame_init() function).


- if (DWARF2_UNWIND_INFO || DWARF2_FRAME_INFO)
-	     initial_return_save (INCOMING_RETURN_ADDR_RTX);

+ if (targetm.debug_unwind_info () == UI_DWARF2
+     || targetm.except_unwind_info (&global_options) == UI_DWARF2)
+    initial_return_save (((fancy_abort ("../../gcc/dwarf2out.c", 4260, __FUNCTION__)), (rtx) 0));


Replacing DWARF2_UNWIND_INFO with targetm.debug_unwind_info() is either incorrect or is incomplete for AVR Target. This remains to be analysed. 

This is a blocker for bug #17994

Created attachment 24475 [details]
patch

Here's an untested patch.  Does this fix the problem for you?  Naturally you'll want to revert it once dwarf2 unwind info is supported.

(In reply to comment #4)
> Created attachment 24475 [details]
> patch
> 
> Here's an untested patch.  Does this fix the problem for you?  Naturally you'll
> want to revert it once dwarf2 unwind info is supported.

I don't think this is a proper fix. Current GCC trunk already has support for DWARF2 CFI emission. But as per internals, emitting CFI can be optional. So unless DWARF2_UNWIND_INFO or INCOMING_RETURN_ADDR_RTX is defined, the function initial_return_save() should not be invoked.

(In reply to comment #4)
> Created attachment 24475 [details]
> patch
> 
> Here's an untested patch.  Does this fix the problem for you?

I'll try and let you know.

>  Naturally you'll
> want to revert it once dwarf2 unwind info is supported.

I think my other comment (#5) is somewhat ambiguous and incomplete. I am referring to TARGET_DEBUG_UNWIND_INFO being defined in avr.c. In previous versions it is optional but now it seems mandatory to avoid ICE.

Created attachment 24478 [details]
alternate patch

This patch is probably better.

(In reply to comment #7)
> Created attachment 24478 [details]
> alternate patch
> 
> This patch is probably better.

I agree. But this does not fully solve the problem either. INCOMING_RETURN_ADDR_RTX is being defined in dwarf2out.c to gcc_unreachable() :-(


http://gcc.gnu.org/viewcvs/tags/gcc_4_6_0_release/gcc/dwarf2out.c?r1=162889&r2=162917

Due to this, we get an ICE - 

../../../../libgcc/../gcc/libgcc2.c: In function '__lshrdi3':
../../../../libgcc/../gcc/libgcc2.c:427:1: internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2677

(In reply to comment #8)
> I agree. But this does not fully solve the problem either.
> INCOMING_RETURN_ADDR_RTX is being defined in dwarf2out.c to gcc_unreachable()
> :-(

Why is initial_return_save still being called?  My patch should prevent debug_unwind_info from returning UI_DWARF2.

(In reply to comment #9)
> (In reply to comment #8)
> > I agree. But this does not fully solve the problem either.
> > INCOMING_RETURN_ADDR_RTX is being defined in dwarf2out.c to gcc_unreachable()
> > :-(
> 
> Why is initial_return_save still being called?  My patch should prevent
> debug_unwind_info from returning UI_DWARF2.


Preprocessed output of default_debug_unwind_info()

enum unwind_info_type
default_debug_unwind_info (void)
{
# 1356 "../../gcc/targhooks.c"
  return UI_NONE;
}


I don't think  initial_return_save() is called now. It passes the compilation there but gets struck in other places. I think it is because INCOMING_RETURN_ADDR_RTX is now seen as defined and hence CFI info is emitted. But this runs into trouble because the above hook is gcc_unreachable().

(In reply to comment #10)
> I don't think  initial_return_save() is called now. It passes the compilation
> there but gets struck in other places. I think it is because
> INCOMING_RETURN_ADDR_RTX is now seen as defined and hence CFI info is emitted.
> But this runs into trouble because the above hook is gcc_unreachable().

It's only defined in dwarf2out.c, and there it's only used in the call to initial_return_save.

(In reply to comment #11)
> (In reply to comment #10)
> > I don't think  initial_return_save() is called now. It passes the compilation
> > there but gets struck in other places. I think it is because
> > INCOMING_RETURN_ADDR_RTX is now seen as defined and hence CFI info is emitted.
> > But this runs into trouble because the above hook is gcc_unreachable().
> 
> It's only defined in dwarf2out.c, and there it's only used in the call to
> initial_return_save.

Right. This is a new problem, explained below.

The ICE results because dwarf2out_frame_debug_expr() is called(which I think should not be called unless INCOMING_RETURN_ADDR_RTX/DWARF2_UNWIND_INFO is defined).The above function(if is not a recursive),is always called from dwarf2out_debug_frame().


dwarf2out_debug_frame() is required to emit frame information if and only if dwarf2out_do_frame() is true. The latter going by comments, is required to determine whether or not to emit a frame related information. Here some ambiguity lies. In earlier versions, calls to dwarf2out_do_frame() are not emitted as they are conditionally compiled (#ifdef DWARF2_UNWIND_INFO )

http://gcc.gnu.org/viewcvs/tags/gcc_4_6_0_release/gcc/final.c?r1=164610&r2=164701&diff_format=h

I think with the above patch, conditional compilation w.r.t DWARF2_UNWIND_INFO macro is removed.  The logic of dwarf2out_do_frame() does not seem to consider INCOMING_RETURN_ADDR_RTX as optional. Whenever write_symbols is defined to DWARF2_DEBUG ( This is set by turning on DWARF2_DEBUGGING_MACRO in opts.c), the function returns true. As a result, dwarf_debug_frame_expr() is always called!

dwarf2out_do_frame() --> dwarf2out_debug_frame() --> dwarf2out_frame_debug_expr()
    

I think the function dwarf2out_do_frame() needs to be updated for optional CFI check. [Not sure if the problem can be solved fully with these changes either]


HTH
Anitha

(In reply to comment #12)

> function returns true. As a result, dwarf_debug_frame_expr() is always called!

Typo - dwarf2out_frame_debug_expr() is always called.


Georg:

Can you change the state to NEW and raise the severity to blocker? I don't have required privileges.

(In reply to comment #13)
 
> Can you change the state to NEW and raise the severity to blocker? I don't have
> required privileges.

I've set state to NEW, but raised the severity to MAJOR. You need to understand that the severity is for the entire GCC project and the AVR target is not even a "secondary" target, even though it might be critical for Atmel.

(In reply to comment #14)
> (In reply to comment #13)
> 
> > Can you change the state to NEW and raise the severity to blocker? I don't have
> > required privileges.
> 
> I've set state to NEW, but raised the severity to MAJOR. You need to understand
> that the severity is for the entire GCC project and the AVR target is not even
> a "secondary" target, even though it might be critical for Atmel.

Correction: Not for Atmel and I am definitely not representing it.

I am going by the definition given in bug's life cycle. A blocker is described as some bug which blocks development and/or testing work. The current bug does when DWARF2 is enabled. But as you said, if more parameters are to be considered, yes, I need to understand them.

rth, this was broken by your change, do do you think it ought to work in the new hookified world?

Created attachment 24512 [details]
loosen constraints on register elimination

This seems to fix the problem.  At least for this small test case.
A full build for AVR fails, but that seems to be related to other
open bugs.

(In reply to comment #17)
> Created attachment 24512 [details]
> loosen constraints on register elimination
> 
> This seems to fix the problem.  At least for this small test case.

I think there are 2 issues here. The first issue deals with avr-gcc which was built without dwarf2 support. The second issue (comment #1 onwards) deals with avr build errors. Maybe we should separate them.


> A full build for AVR fails, but that seems to be related to other
> open bugs.

Please let me know if any other known bugs exist with regarding to build failure. AFAIK, there are some open PRs for emitting CFI information but not for build failures (Bug #44643 is fixed)

But the current 4.6.0 build is without CFI support, which is possible as CFI is optional. As far as I have analyzed, AVR build with DWARF2 support fails with the reasons discussed in comment #3 (and later on). All the changes were made in 4.6.0 release. Since the build is known to pass in 4.5.x release, this is a regression. And I think we need to address these issues as part of this bug.

(In reply to comment #17)

> A full build for AVR fails, but that seems to be related to other
> open bugs.

What bugs? 

I can build avr-gcc SVN 175011 from today without problems on i686-pc-linux-gnu + gcc 4.3.2.

Target: avr
Configured with: ../../gcc.gnu.org/trunk/configure --target=avr --prefix=/local/gnu/install/gcc-4.7 --disable-nls --disable-shared --enable-languages=c,c++
Thread model: single
gcc version 4.7.0 20110614 (experimental) (GCC)

GNU assembler version 2.21 (avr) using BFD version (GNU Binutils) 2.21

GMP 5.0.1
MPFR 3.0.0
MPC 0.8.2

(In reply to comment #19)
> > A full build for AVR fails, but that seems to be related to other
> > open bugs.
> 
> What bugs? 

Perhaps I shouldn't assume.

../../../../../../comb/newlib/libc/search/hash.c: In function ‘__expand_table’:
../../../../../../comb/newlib/libc/search/hash.c:898:1: error: unable to find a register to spill in class ‘POINTER_REGS’
../../../../../../comb/newlib/libc/search/hash.c:898:1: error: this is the insn:
(insn 190 97 191 10 (set (reg:QI 18 r18)
        (mem/c:QI (plus:HI (reg/f:HI 28 r28)
                (const_int 5 [0x5])) [14 S1 A8])) ../../../../../../comb/newlib/libc/search/hash.c:886 4 {*movqi}
     (nil))
../../../../../../comb/newlib/libc/search/hash.c:898:1: internal compiler error: in spill_failure, at reload1.c:2113
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[8]: *** [lib_a-hash.o] Error 1
make[8]: Leaving directory `/home/rth/work/gcc/bld-avr/avr-elf/avr25/newlib/libc/search'

I saw r28 in there and assumed it was the same problem with the
frame pointer as PR46779.

Anyway, I believe I've fixed the problem for #c0.  I'll commit it shortly.

Author: rth
Date: Tue Jun 14 13:31:43 2011
New Revision: 175018

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175018
Log:
PR debug/48459
        * dwarf2out.c (frame_pointer_fb_offset_valid): New.
        (based_loc_descr): Assert it's true.
        (compute_frame_pointer_to_fb_displacement): Set it, rather than
        aborting immediately.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/dwarf2out.c

(In reply to comment #20)
> (In reply to comment #19)
> > > A full build for AVR fails, but that seems to be related to other
> > > open bugs.
> > 
> > What bugs? 
> 
> Perhaps I shouldn't assume.
> 
> ../../../../../../comb/newlib/libc/search/hash.c: In function ‘__expand_table’:
> ../../../../../../comb/newlib/libc/search/hash.c:898:1: error: unable to find a
> register to spill in class ‘POINTER_REGS’
> ../../../../../../comb/newlib/libc/search/hash.c:898:1: error: this is the
> insn:
> (insn 190 97 191 10 (set (reg:QI 18 r18)
>         (mem/c:QI (plus:HI (reg/f:HI 28 r28)
>                 (const_int 5 [0x5])) [14 S1 A8]))
> ../../../../../../comb/newlib/libc/search/hash.c:886 4 {*movqi}
>      (nil))
> ../../../../../../comb/newlib/libc/search/hash.c:898:1: internal compiler
> error: in spill_failure, at reload1.c:2113

Oh, I doubt newlib works with avr-gcc. There is just one libc implementation that cooperates with avr-gcc: avr-libc from
http://avr-libc.nongnu.org/

Note that avr-libc does not support in-tree builds, just set --host=avr CC=/your/avr-gcc

Author: rth
Date: Tue Jun 14 19:13:00 2011
New Revision: 175049

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175049
Log:
PR debug/48459
        * dwarf2out.c (frame_pointer_fb_offset_valid): New.
        (based_loc_descr): Assert it's true.
        (compute_frame_pointer_to_fb_displacement): Set it, rather than
        aborting immediately.

Modified:
    branches/gcc-4_6-branch/gcc/ChangeLog
    branches/gcc-4_6-branch/gcc/dwarf2out.c

The testcase at the head of the PR is now fixed.

For the 4.6 branch, this required also backporting

2011-03-22  Richard Henderson  <rth@redhat.com>

       * config/avr/avr.c (TARGET_EXCEPT_UNWIND_INFO): New.
       (avr_incoming_return_addr_rtx): New.
       (emit_push_byte): New.
       (expand_prologue): Use it.  Remove incorrect dwarf annotation for
       SREG, RAMPZ, zero register.  Push frame pointer by bytes.  Add dwarf
       annotation for __prologue_saves__.  Fixup dwarf annotation for CFA.
       (emit_pop_byte): New.
       (expand_epilogue): Use it.  Pop frame pointer by bytes.
       * config/avr/avr.h (FRAME_POINTER_CFA_OFFSET): Remove.
       (INCOMING_RETURN_ADDR_RTX): New.
       (INCOMING_FRAME_SP_OFFSET): New.
       (ARG_POINTER_CFA_OFFSET): New.
       * config/avr/avr.md (*pushqi): Fix mode of auto-inc.
       (*pushhi, *pushsi, *pushsf, popqi): Likewise.
       (pophi): Remove.

from mainline.

(In reply to comment #24)
> The testcase at the head of the PR is now fixed.
> 
> For the 4.6 branch, this required also backporting
> 


(Assuming that backporting implies the emission of DWARF2 CFI) Is it not possible to drop DWARF2 CFI feature (which is optional) and still make 4.6x build successful? It is quite possible that some target might want to do this.

If the intention is to make CFI mandatory, then internals document should be updated as well.

(In reply to comment #25)
> (Assuming that backporting implies the emission of DWARF2 CFI) Is it not
> possible to drop DWARF2 CFI feature (which is optional) and still make 4.6x
> build successful? It is quite possible that some target might want to do this.

Um.  Why?  This is not using dwarf2 cfi for unwinding; that is
still using setjmp.  This is using dwarf2 cfi for debugging,
which is exactly what you asked for when you said -gdwarf-2.

If you mean the assembler .cfi directives, you do not need
that in order for the build to succeed.  But that is detected
at configure time; if you have an assembler that accepts them
we will emit them, otherwise we'll emit the cfi data as .byte.

If you mean something else, I don't know what it is.

(In reply to comment #24)
> The testcase at the head of the PR is now fixed.

I could build avr-gcc from trunk and run couple of simple testcases.

[anitha@turing objdir]$ avr-gcc -v
Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/home/anitha/install/libexec/gcc/avr/4.7.0/lto-wrapper
Target: avr
Configured with: ../configure --target=avr --prefix=/home/anitha/install/ --with-dwarf2 --enable-languages=c --disable-libssp --disable-nls --with-gmp=/proj/install/gmp-4.3.2/ --with-mpc=/proj/install/mpc-0.8.2/ --with-mpfr=/proj/install/mpfr-2.4.2/ CFLAGS=-g
Thread model: single
gcc version 4.7.0 20110615 (experimental) (GCC) 


> 
> For the 4.6 branch, this required also backporting

Any idea if the build succeeded for 4.6 branch? I tried and it failed. (branch: gcc-4_6-branch)


../../../../libgcc/../gcc/libgcc2.c: In function '__lshrdi3':
../../../../libgcc/../gcc/libgcc2.c:427:1: internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2671
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[4]: *** [_lshrdi3.o] Error 1
make[4]: Leaving directory `/home/anitha/gcc-4.6-branch/objdir/avr/avr25/libgcc'
make[3]: *** [multi-do] Error 1
make[3]: Leaving directory `/home/anitha/gcc-4.6-branch/objdir/avr/libgcc'

(In reply to comment #24)
> The testcase at the head of the PR is now fixed.

I could build avr-gcc from trunk and run couple of simple testcases.

[anitha@turing objdir]$ avr-gcc -v
Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/home/anitha/install/libexec/gcc/avr/4.7.0/lto-wrapper
Target: avr
Configured with: ../configure --target=avr --prefix=/home/anitha/install/ --with-dwarf2 --enable-languages=c --disable-libssp --disable-nls --with-gmp=/proj/install/gmp-4.3.2/ --with-mpc=/proj/install/mpc-0.8.2/ --with-mpfr=/proj/install/mpfr-2.4.2/ CFLAGS=-g
Thread model: single
gcc version 4.7.0 20110615 (experimental) (GCC) 


> 
> For the 4.6 branch, this required also backporting

Any idea if build succeeded for 4.6 branch? I tried and it failed. (branch: gcc-4_6-branch)


../../../../libgcc/../gcc/libgcc2.c: In function '__lshrdi3':
../../../../libgcc/../gcc/libgcc2.c:427:1: internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2671
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[4]: *** [_lshrdi3.o] Error 1
make[4]: Leaving directory `/home/anitha/gcc-4.6-branch/objdir/avr/avr25/libgcc'
make[3]: *** [multi-do] Error 1
make[3]: Leaving directory `/home/anitha/gcc-4.6-branch/objdir/avr/libgcc'

Works For Me.

[rth@anchor bld-avr-46]$ size avr/avr25/libgcc/_lshrdi3.o
   text	   data	    bss	    dec	    hex	filename
    244	      0	      0	    244	     f4	avr/avr25/libgcc/_lshrdi3.o

Created attachment 24552 [details]
Make log for gcc-4_6-branch for comment 28

(In reply to comment #29)
> Works For Me.
> 
> [rth@anchor bld-avr-46]$ size avr/avr25/libgcc/_lshrdi3.o
>    text       data        bss        dec        hex    filename
>     244          0          0        244         f4   
> avr/avr25/libgcc/_lshrdi3.o


I have clean built multiple times now and it fails all the times with the same message. I have got atleast one response in avr-gcc-list reporting the same error. Also attached the log. Can you double check if dwarf2 is enabled?

svn entries file -

dir
175135
http://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch
http://gcc.gnu.org/svn/gcc

---
http://lists.gnu.org/archive/html/avr-gcc-list/2011-06/msg00034.html

You're right.  And now I remember the other patch to dwarf2out.c
that went along with fixing up the errors in avr.c wrt dwarf2.
I must backport them both.

Fixed with:

2011-06-17  Richard Henderson  <rth@redhat.com>

        Backport from mainline
        2011-03-22  Richard Henderson  <rth@redhat.com>

        * dwarf2out.c (dwarf2out_frame_debug_expr) [rule 11]: Handle post_dec.

(In reply to comment #32)
> Fixed with:
> 
> 2011-06-17  Richard Henderson  <rth@redhat.com>
> 
>         Backport from mainline
>         2011-03-22  Richard Henderson  <rth@redhat.com>
> 
>         * dwarf2out.c (dwarf2out_frame_debug_expr) [rule 11]: Handle post_dec.

Great! Build succeeds now. I am yet to test it. Thanks Richard.

Anitha