[RFA] Enhance stabs reader to better deal with forward references

[Joel Brobecker <brobecker at adacore dot com>]

Hello,

Yep, you read right, some of us are still stuck with stabs. This is
still being used on pa32-hpux and ppc-aix. The case that concerns us,
this time, is on ppc-aix. Incidentally, we're trying to add support
for DWARF on AIX, and we actually managed to get a first prototype
going, but there are still many many details we need to iron out
before we declare success.

In the meantime, I had this curious failure. We hit this problem
only with an old testcase that uses some code that was given to
us by a customer, so I cannot send you the entire code. What's
interesting, however, is that we're dealing with procedure parameter
of type float. The debugging info looks like this:

        .stabx  "float:t243=r8;4;0;",0,140,0
        [...FOLLOWED by...]
        .stabx  "incomplete:p268=k243",100,130,0

However, the fun starts after the assembler (we use the native
assembler) actually swaps the two stabs. So we end up seeing
in the object file the stabs for incomplete BEFORE the stabs
for type float.

The current stabs reader is not really designed to handle this
case, and one could also argue that this is an assembler bug,
since we could argue that stabs assumes that the entries should
be ordered properly.

Nonetheless, it turned out that adding support for misordered
entries was relatively easy, at the cost of an extra table.

That's not where the fun stops, however. The code handling
const types looks like this:

    case 'k':                   /* Const qualifier on some type (Sun) */
      type = read_type (pp, objfile);
      type = make_cv_type (1, TYPE_VOLATILE (type), type,
                           dbx_lookup_type (typenums));
      break;

In our case, the "make_type" call ended up returning an undefined
type, and then we end up making a "const" copy of that undefined
type when calling "make_cv_type".

The problem is that type 268 (our const type) is "complete", and
no future stabs entry will ammend it. So even though I some handling
for forward references of the kind above, this was not sufficient
because the type attached to our parameter was still an undefined
type.

That's why I modified this part of the code to make the cv type
only when the target type was already defined. Otherwise, we give
up the "const" qualifier and reuse the target type instead. We
know that this target type will be fixed up later, so our parameter
will have a defined type, and we'll be able to print it. We end up
losing the "const" qualifier, but this is still way better than
not having any type at all.

2007-02-08  Joel Brobecker  <brobecker@adacore.com>

        * stabsread.c (add_undefined_type): Add extra parameter.
        Now handles nameless types separately.
        (struct nat): New type.
        (noname_undefs, noname_undefs_allocated, noname_undefs_length):
        New static variables.
        (read_type): Update calls to add_undefined_type.
        Do not create an equivalent cv type if the type referenced
        has not been defined yet.
        (add_undefined_type_noname): New function.
        (add_undefined_type_1): Renames from add_undefined_type.
        (cleanup_undefined_types_noname): New function.
        (cleanup_undefined_types_1): Renames cleanup_undefined_types.
        (cleanup_undefined_types): New handles nameless types separately.
        (_initialize_stabsread): Initialize our new static constants.

Tested on ppc-aix and x86-linux, no regression. Fixes the problem at
hand.  OK to apply?

Thanks,
-- 
Joel

Attachment: stabs-public3.diff
Description: incomplete.diff