Re: advice wanted on complex obstack bug...

[Jeffrey A Law <law at upchuck dot cygnus dot com>]

  In message <v04020a01b270ffd7f4ba@[192.168.1.254]>you write:
  > I've tracked down a subtle (but nasty) bug in the following
  > complex situation....
  > 
  > 
  > 1/ Compiling 'inlined' functions
  > 2/ using SDB debug symbols
  > 
  > I suppose there may be other ways that this can happen, but...
  > 
  > Here's the basic situation.
  > 
  > 	When compiling a function we allocate the tree for declarations
  > 	and types into the maybepermanent obstack.  When we decide that
  > 	this is a candidate for inlining, we call preserve_data() to
  > 	set the high-water-mark to keep the important data structures
  > 	from being deleted.
  > 
  > 	Now, suppose we have declared stack variable with an
  > 	anonymous type
  > 
  > 		char buffer[] = { "some text here..."};
  > 
  > 	When we get to the point of outputting the debug information
  > 	for the function, we find ourselves in sdbout_symbol() and
  > 	want to put out type information for 'buffer'.
  > 
  > 	We eventually find ourselves in the case where we're actually
  > 	treating this as if it was a pointer to a variable amount
  > 	of data.  We do a
  > 
  > 		type = build_pointer_type (TREE_TYPE (decl));
  > 
  > 	and build_pointer_type() discovers that there is no TYPE_POINTER_TO
  > 	value yet, so it allocates one on the same stack as the type
  > 	pointed-to.
  > 
  > BUT, THAT OBSTACK HAS BEEN MARKED WITH A CALL TO PRESERVE_DATA()!
  > 
  > 	Now, we've got a preserved type "array-of-char" that points
  > 	to a "pointer-to-array-of-char" that is on the wrong
  > 	side of the high-water mark....
  > 
  > 
  > I'm not quite sure of how to fix this (and I've simplified the
  > problem somewhat.  My test case is 2000 lines of source code...)
  > 
  > Just calling preserve_data() from inside sdbout_symbol() seems
  > like an overly large hammer.....
  > 
  > The only other approach that occurs to me is to change
  > the way we call plain_type() so that we indicate that an EXTRA
  > level of indirection in required - thereby avoiding the
  > build_pointer_type() call completely!
[ If it's not obvious to everyone by now, I'm going to lots of old unanswered
  bug reports & questions :-) ]

Here's a tidbit from dbxout.c which appears to be dealing with the same
situation:

      /* Effectively do build_pointer_type, but don't cache this type,
         since it might be temporary whereas the type it points to
         might have been saved for inlining.  */
      /* Don't use REFERENCE_TYPE because dbx can't handle that.  */
      type = make_node (POINTER_TYPE);
      TREE_TYPE (type) = TREE_TYPE (decl);

Then presumably it uses the type, then throws it away. without attaching
it to the original node's TYPE_POINTER_T field.

jeff