Re: protection from dangling pointers in dwarf info when .so's go away

["Doug Evans" <dje@google.com>]

On Dec 13, 2007 8:56 AM, Jim Blandy <jimb@codesourcery.com> wrote:
>
>
> Daniel Jacobowitz <drow at false.org> writes:
> > On Thu, Dec 13, 2007 at 12:16:36AM -0800, Doug Evans wrote:
> >> What happens if TYPE_OBJFILE (type) != TYPE_OBJFILE
> >> (TYPE_VPTR_BASETYPE (baseclass)) ?
> >
> > Precisely what you saw, but how does this happen?  The baseclass links
> > should normally point through to other types in the same objfile.
> >
> > I'm guessing that there was inadequate debug info for a base class,
> > leading GDB to do name resolution into a shared library with better
> > debug info (probably because it defined the class's key method)?
>
> If I remember right, the way we usually handle this is by leaving the
> types from the main executable 'incomplete', as if it had just seen
> 'struct foo' but no definition for it.  When we need the full
> definition of 'struct foo', we look it up by name, find it whereever
> it happens to be available, and use it there.  So we do an extra name
> lookup, because that allows the reference to break naturally when
> objfiles are freed.
>
> But there shouldn't be pointers between objfiles, for the reasons
> stated.

It turns out all that's needed is for the baseclass in question live in a .so.
I filed 2384, and will submit a proposed patch shortly.