This is the mail archive of the gdb-patches@sourceware.org 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]

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


> On Fri, Feb 09, 2007 at 11:41:07AM -0800, Joel Brobecker wrote:
> > 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.
> 
> I really don't like this part.  I don't understand it, either.  Why is
> the CV type complete?  When the non-qualified type is filled in, that
> should automatically fill this in, because of the CV ring.  See the
> implementation of replace_type.

Thanks for the carefule review, Daniel.

I need to get back into this again. I am not familiar with the TYPE_CHAIN
ring so I didn't realize that replace_type should do the work. Looking
at the code in replace_type, there is something I don't understand:

      /* The type length is not a part of the main type.  Update it for each
         type on the variant chain.  */
      chain = ntype;
      do {
        /* Assert that this element of the chain has no address-class bits
           set in its flags.  Such type variants might have type lengths
           which are supposed to be different from the non-address-class
           variants.  This assertion shouldn't ever be triggered because
           symbol readers which do construct address-class variants don't
           call replace_type().  */
        gdb_assert (TYPE_ADDRESS_CLASS_ALL (chain) == 0);
    
 -->    TYPE_LENGTH (ntype) = TYPE_LENGTH (type);
        chain = TYPE_CHAIN (chain);
      } while (ntype != chain);

Shouldn't it be "chain" instead of "ntype" here?

-- 
Joel


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