PR1170: wrong assumption on stab = crash

PR1170: wrong assumption on stab = crash

[Michael Veksler]

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).

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

[Michael Veksler]

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).

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

[Joel Brobecker]

On Thu, Sep 23, 2004 at 12:23:37PM +0200, Michael Veksler wrote:
> 
> This is a bug long overdue, and makes C++ debugging on AIX impossible.

I'd like to know how the other GDB maintainers feel about this bug
report. I don't think that we should use a reproducer that forces us
to switch stabs lines like this. I'd much rather use a real testcase.
That way, I feel more comfortable knowing that I am fixing a real bug,
and we can then add the testscase to our testsuite once the bug is fixed.

Opinions?

Michael,

would have some code that would demonstrate the problem without
the fiddling? I just looked at the testsuite results on AIX, where
I use GCC 3.2.3 configured with C,C++ and Ada, and I didn't see any
such internal-error.

BTW, here are the results for the entire gdb.cp testcases (all our
C++ testcases):

                        === gdb Summary ===
        
        # of expected passes            1681
        # of unexpected failures        50
        # of expected failures          2
        # of known failures             23
        # of unresolved testcases       2

This is with sources from CVS as of yesterday.


> 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).
> 
> 
> 
> 
> 

-- 
Joel

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

[Michael Veksler]

Joel Brobecker <brobecker@gnat.com> wrote on 2004-09-23 18:45:27:

> Michael,
>
> would have some code that would demonstrate the problem without
> the fiddling? I just looked at the testsuite results on AIX, where
> I use GCC 3.2.3 configured with C,C++ and Ada, and I didn't see any
> such internal-error.
>

There is a real test case in the PR. It generates inputs too big to
understand. If you look at the PR, you can see my analysis that start
with this huge test case, and reduced to simple several lines
that do require fiddling. Unfortunately, /bin/as does not guarantee
order preservation, which makes my fiddling valid:
1. Since future versions of /bin/as may reorder things this way.
2. Any technology that does post link optimization will cause
   such problems. I would suspect that FDPR will make the simplest
   C code impossible to debug in GDB.
      http://www.haifa.il.ibm.com/projects/systems/cot/fdpr/

The test case is as simple as:
      $ cat bug.cpp
      #include <string>
      #include <iostream>
      int main() {}
      $ g++ -g -fno-inline -fno-default-inline bug.cpp

Note that these flags are critical if you don't want an even bigger
tests case.