GDB unusable on AIX and lucky to work on HP-UX (PR1170)

[Michael Veksler <VEKSLER@il.ibm.com>]

This is a bug long overdue, and makes C++ debugging on AIX impossible.
I could reproduce it for simple C code:
      /* compile with gcc -g -S */
      int get_int1() { const int zero= 0; return zero; }
      int get_int2() { const int zero= 0; return zero; }
      int main() { return 0; }

If you reorder get_int1 and get_int2 in the ASM file gdb will crash.
(/bin/as is allowed to do so, and it does reorder in big test cases).
This reordering works fine when compiled with gcc -gstabs on Linux.


It seems to be triggered by the combination of stabs and COFF. Since
HP-UX seems to be COFF based I suspect that HP-UX is also affected.
Can someone confirm this?

I seek for advice on how to correctly fix for this.

There are 3 ways:
1. Make gdb behave well when it reads debug info in a "wrong" order.
   Any advice on this is welcome.
2. Change gcc to emit =k-{n} (e.g. =k-1) for all instances of constant
   built-in type (instead of only once per type).
   This is the patch this PR mentions, but David Edelsohn objects
   because he thinks it is the wrong way to fix it.
      If =k-{n} is required to repeat by stabs format, then it means that
the correct fix *is*
      in gcc and should resemble my patch.
3.  Change gcc to avoid =k-{n} format altogether in these cases.

I think that solution 1 is the correct one. I looked at xlC output and
came to realize that xlC may trigger the same bug in gdb (if gdb
understood xlC's C++).



                                                                           
             Michael                                                       
             Veksler/Haifa/IBM                                             
             @IBMIL                                                     To 
             Sent by:                  gdb@sources.redhat.com              
             gdb-owner@sources                                          cc 
             .redhat.com                                                   
                                                                   Subject 
                                       PR1170: wrong assumption on stab =  
             20/09/2004 13:34          crash                               
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=1170


1. First I'll describe how to reproduce (will probably
   crash on other stab+coff systems)
2. Later I'll explain why this happens.
3. Then I'll ask how this should be fixed.

---- How to reproduce ----
On AIX, (maybe on other systems) the folding will crash
gdb (5.3, and as I remember, 6.0 and later):
      // g++ -g
      struct X { static const int firstInt = 0; };
      struct Y { static const int secondInt = 0; };
      int main() { }

Move the stabstring about 'firstInt' till after the
stabstring about 'main' (something that /bin/as and
/bin/ld are allowed to do).
Now, in gdb do either:
      'ptype Y', or 'break main'

At this point you should get:
gdbtypes.c:515: gdb-internal-error: make_cv_type: Assertion `TYPE_OBJFILE
(*typeptr) == TYPE_OBJFILE (type) || TYPE_STUB (*typeptr)' failed.
An internal GDB error was detected.  This .......

---- What causes the crash ----

'firstInt' is assigned a new type-id (13) which is a typedef
of the build in 'int':
      X:Tt12=s1firstInt:/213=k-1:........
                         ^^ ^^^
                    type-id   built-in type (1 == int).

'secondInt' reuses the same type-id:
      Y:Tt21=s1secondInt:/213:....
                          ^^
                       type-id

Now /bin/as or /bin/ld move firstInt stabstring much
after secondInt.

GDB reads the symbols in order:
1. secondInt:/213,  gdb puts a new type-id = 13 in a symbol table.
   This is an incomplete type.
2. firstInt:/213=k-1, oops this is not an incomplete type but
   a const built-in type. An assertion in make_cv_type fails.
   A comment preceding this assertion reads:
   /* Objfile is per-core-type.  This const-qualified type had best
      belong to the same objfile as the type it is qualifying, unless
      we are overwriting a stub type, in which case the safest thing
      to do is to copy the core type into the new objfile.  */
---- How to fix ----
Removing the assertion does not resolve the core issue.
Is it possible to update change type information when GDB
learns more about the type? It must be the case for:
      struct A ;
      struct A { /* some stuff */ };
Why is it not the case for 'static const int firstInt=0' ?
Is there something deep in the infrastructure that prevents
this? Is it because of late addition of c-v (const/volatile)?
Is it a bug in gcc - which should emit "13=k-1" every time
instead of plain "13" (it should not loose the const qualifier).