Inconsistent g++3.2 debug information on AIX

[Michael Veksler]

You can read my message on gdb mailing list regarding their side of the 
problem:
   http://sources.redhat.com/ml/gdb/2003-08/msg00305.html

g++3.2.1 generates inconsistent debug (stubs) information on AIX which 
makes gdb crash. It is trivial to reproduce the bug on gcc 3.2.1:

// compile with g++ -g -fno-inline -fno-default-inline test.cpp
#include <string>
#include <iostream>
int main() {}

Running the latest gdb (from CVS or 5.3) on the resulting a.out will
make it crash.

Here are some highlights from my mail to the gdb mailing-list:

I gathered the following debug information through "nm -Cpf test.o".

The following line introduces a new typedef to "unsigned int". This
new type is given id=1749:

_ZNKSt5ctypeIcE5tableEv:f1898=*1749 -       5044

The bug is:
This is the first occurrence of this type in the output.
This line lacks "=k-8" to associate 1749 with unsigned int.
This causes gdb to think that this is a user type.
The correct line would have been:
_ZNKSt5ctypeIcE5tableEv:f1898=*1749=k-8 -       5044

This bug makes gdb build wrong data structure for this type. Later
on when GDB tries to access 1749 again, it detects inconsistency
and an assertion fails. This crash happens when gdb gets to:
locale:Tt1748=s4none:/21749=k-8:_ZNSt6locale4noneE;cty......

When gdb suddenly realizes that 1749 is a builtin type, and not a
user type it crashes.

Unfortunately, gcc manifests the bug in a very narrow case.
Any attempt to reduce the size of the preprocessed code made
the bug go away. It is possible that it is impossible to reporodcue
this bug in the same way with newer gcc - even though it is still
there. 

This means that if this bug cannot be reproduced with gcc-3.3,
it should be analyzed on gcc-3.2. After the cause of the bug is
detected, only then newer gcc's should be checked.

I don't want to open a new PR under gcc-3.2's branch, because
it will get buried there. Should I open a new PR now or wait for basic
analysis first?