This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

PR1170: wrong assumption on stab = 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).





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]