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

[Joel Brobecker <brobecker@gnat.com>]

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