This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
PR1170: wrong assumption on stab = crash
- From: Michael Veksler <VEKSLER at il dot ibm dot com>
- To: gdb at sources dot redhat dot com
- Date: Mon, 20 Sep 2004 13:34:34 +0300
- Subject: 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).