Re: debug/7032: arm-elf-gcc 3.1 generates wrong DWARF-2, unlike 3.0.4

Re: debug/7032: arm-elf-gcc 3.1 generates wrong DWARF-2, unlike 3.0.4

[rearnsha]

Synopsis: arm-elf-gcc 3.1 generates wrong DWARF-2, unlike 3.0.4

State-Changed-From-To: open->feedback
State-Changed-By: rearnsha
State-Changed-When: Mon Sep 30 06:42:30 2002
State-Changed-Why:
    This sounds more like a bug in AXD than in gcc.  GCC is designed to work with GDB as the primary consumer of the debug information.  If you want this problem to be fixed then you will have to supply details of precisely what debug information is causing the problem.  Remember that most gcc developers don't have access to AXD.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7032

Re: debug/7032: arm-elf-gcc 3.1 generates wrong DWARF-2, unlike 3.0.4

[rearnsha]

Synopsis: arm-elf-gcc 3.1 generates wrong DWARF-2, unlike 3.0.4

State-Changed-From-To: feedback->closed
State-Changed-By: rearnsha
State-Changed-When: Fri Jan 31 16:28:05 2003
State-Changed-Why:
    While it would be nice to be able to use AXD with GCC compiled code, there's not really very much we can do here.  AXD isn't a GNU-supported debugger, and GCC isn't a compiler supported by ARM for use with AXD (In reallity, AXD will probably only work with code compiled by ARM's compiler).  I do understand that ARM's new debugger (RealView Debugger) is much better and handling DWARF from sources other than ARM's own compiler; and as the EABI specification for the ARM progresses, I can see interworking between debuggers becoming much more important. 
    
    But in the mean time, there's little point in keeping this report open

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7032

Re: debug/7032: arm-elf-gcc 3.1 generates wrong DWARF-2, unlike 3.0.4

[Adrian Bocaniciu]

The following reply was made to PR debug/7032; it has been noted by GNATS.

From: "Adrian Bocaniciu" <a.bocaniciu@computer.org>
To: <rearnsha@gcc.gnu.org>, <a.bocaniciu@computer.org>, <gcc-bugs@gcc.gnu.org>,
   <gcc-prs@gcc.gnu.org>, <nobody@gcc.gnu.org>, <gcc-gnats@gcc.gnu.org>
Cc:  
Subject: Re: debug/7032: arm-elf-gcc 3.1 generates wrong DWARF-2, unlike 3.0.4
Date: Wed, 2 Oct 2002 16:09:07 -0000

 >     This sounds more like a bug in AXD than in gcc.  GCC is designed to
 work with GDB as the primary consumer of the debug information.  If you want
 this problem to be fixed then you will have to supply details of precisely
 what debug information is causing the problem.  Remember that most gcc
 developers don't have access to AXD.
 >
 
     You might be right, of course.  However it is hard to tell
 because the error message from AXD was very uninformative.
 Still, the bug might also be in gcc, especially since it appeared
 after a version change.  That is the reason why I reported
 the bug, which completely prevents the use of gcc in
 such an environment.
 
     Unfortunately, I did not have time to investigate the exact cause
 and I have rolled back to gcc 3.0.4, which works.
 
     Nonetheless, someone who knows what has changed in the
 DWARF generation between 3.0.4 and 3.1 (and also 3.1.1,
 which exhibits identical behavior) should be able to discover
 the origin.
 
     AXD crashed regardless of the compiled program, and
 the problem was located in the two sections indicated
 in my bug report.
 
     All these facts (changes between 3.0.4 and 3.1 in the two
 specified DWARF sections and independence between  the
 crash and the code of the compiled program) should narrow
 enough the possible choices for the cause.
 
     When I will find some time, I will further investigate the problem.
 I also had problems with binutils, but there I was able to find
 quickly the bug and patch the binutils sources.
 
     I would rather use gdb than AXD, which is full of other bugs,
 but there is no way to connect gdb to my boards.  The only
 ARM debug interfaces that gdb knows about are those from
 Macraigor but their support is incomplete because there is
 no way to define a JTAG chain with multiple devices.
 
     Therefore, until I will have time to reverse-engineer any
 of the existing ARM debug interfaces and add the right code
 to gdb, I must use AXD.  And even if I do the reverse-engineering,
 it is probable that I will not be able to contribute the corresponding
 device drivers to the main distribution of gdb because of the
 existing abusive laws for copyright protection.
 
                                                     Best regards !