This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


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

advice wanted on complex obstack bug...


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!

-- Al Lehotsky

------------------------------------------------------------------------

		    Quality Software Management
		http://www.tiac.net/users/lehotsky
			lehotsky@tiac.net
			(978)287-0435 Voice
			(978)287-0436 Fax/Data

	Software Process Improvement and Management Consulting
	     Language Design and Compiler Implementation


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