http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60387
Bug ID: 60387 Summary: The gcc compiler for the ppc architecture is not compatible with PPC ABI and DWARF standards. Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: m_nistor at yahoo dot com The gcc compiler for the ppc architecture doesn't use DWARF Register Number Mapping that is defined in the PPC ABI standards. Just an example for the first vector register (vr0): the ppc gcc generates 100 instead of 1124. The gcc compiler doesn't emit .debug_frame section and it prefers to emit only the .eh_fram e section. The .eh_frame section is used by application to handle the exception. This section is part of the C++ ABI. The .eh_frame section is not a debug section and this section should not be used by debugger for unwinding stack frame, this statement was also done by Michael Eager who is Chair of DWARF Standards Committee Members. You can see below more information about this: http://wiki.dwarfstd.org/index.php?title=Exception_Handling Relationship with DWARF Although the C++ ABI data in the .eh_frame section uses the data format described by the DWARF Standard (with some extensions), this section (and other sections used by exception handling, such as .eh_frame_hdr and .gcc_except_table) are not defined by the DWARF Standard. The DWARF Standard does not describe the extensions to support exception handling nor the routines which must be called by a program to use this data. The DWARF Debugging Format Committee does not specify the contents of these sections or the functionality which must be provided by the language run time system to support exception handling. The .eh_frame section is not used for debugging. Whether it is generated or not is independent of whether DWARF debug data is generated. All DWARF data is contained in sections with names starting with .debug, which may be removed from a program without affecting the program's normal execution. It is common practice to "strip" debugging sections from a program before putting it into production, either to reduce the program size, make reverse engineering more difficult, or both. Removing the .eh_frame section (whether the DWARF .debug sections are left in place or not) has a high likelihood of adversely affecting a program's behaviour, especially when it encounters an unexpected condition. Unfortunately, it has been a common shorthand to refer to the C++ ABI exception handling methodology using .eh_frame with "DWARF exception handling," or similar phrases. Perhaps this because it is easier to say this than the unwieldy "C++ exception handling using the DWARF Call Frame Information format with extensions", or the misleading "C++ ABI for IA-64" or "SVR4 ABI AMD64 Processor Supplement", especially when discussing a processor other than Itanium or AMD-64. This leads to occasional confusion, where people may look at the DWARF Specification for a description of the C++ ABI exception handling method, or where vulnerabilities in the EH scheme are incorrectly characterized as DWARF vulnerabilities, as in the otherwise excellent paper mentioned below.