This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

[PATCH] More unresolved symbol problems with -gstabs


Hello,

we've already experienced 'unresolved symbol' linker errors caused by 
stabs containing references to optimized-out constant pool entries:
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg00767.html

Unfortunately, even with this patch, we're now getting another instance
of the problem.  This time it happens because the variable in question
is *uninitialized*, and thus the code in dbxout_symbol_location that is
supposed to handle constant pool references doesn't even trigger.

The patch below fixes the problem by treating uninitialized variables
the same as initialized ones here.

Note that the test case triggers the problem only on GCC 3.4; on CVS
head the tree-level optimizers already eliminate the variable.  (The
test case was reduced from a real-world problem building the Linux
kernel with -gstabs for lcrash analysis.)

Bootstrapped/regtested on s390-ibm-linux and s390x-ibm-linux on 
CVS head and 3.4; OK for both?

Bye,
Ulrich


ChangeLog:

	* dbxout.c (dbxout_symbol_location): Resolve constant pool references
	even for variables with NULL DECL_INITIAL.

testsuite/ChangeLog:

	* gcc.dg/20041216-1.c: New test.

Index: gcc/dbxout.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/dbxout.c,v
retrieving revision 1.216
diff -c -p -r1.216 dbxout.c
*** gcc/dbxout.c	9 Dec 2004 10:54:32 -0000	1.216
--- gcc/dbxout.c	16 Dec 2004 18:08:29 -0000
*************** dbxout_symbol_location (tree decl, tree 
*** 2733,2738 ****
--- 2733,2769 ----
  
  	  letter = decl_function_context (decl) ? 'V' : 'S';
  
+ 	  /* Some ports can transform a symbol ref into a label ref,
+ 	     because the symbol ref is too far away and has to be
+ 	     dumped into a constant pool.  Alternatively, the symbol
+ 	     in the constant pool might be referenced by a different
+ 	     symbol.  */
+ 	  if (GET_CODE (addr) == SYMBOL_REF
+ 	      && CONSTANT_POOL_ADDRESS_P (addr))
+ 	    {
+ 	      bool marked;
+ 	      rtx tmp = get_pool_constant_mark (addr, &marked);
+ 
+ 	      if (GET_CODE (tmp) == SYMBOL_REF)
+ 		{
+ 		  addr = tmp;
+ 		  if (CONSTANT_POOL_ADDRESS_P (addr))
+ 		    get_pool_constant_mark (addr, &marked);
+ 		  else
+ 		    marked = true;
+ 		}
+ 	      else if (GET_CODE (tmp) == LABEL_REF)
+ 		{
+ 		  addr = tmp;
+ 		  marked = true;
+ 		}
+ 
+ 	      /* If all references to the constant pool were optimized
+ 		 out, we just ignore the symbol.  */
+ 	      if (!marked)
+ 		return 0;
+ 	    }
+ 
  	  /* This should be the same condition as in assemble_variable, but
  	     we don't have access to dont_output_data here.  So, instead,
  	     we rely on the fact that error_mark_node initializers always
*************** dbxout_symbol_location (tree decl, tree 
*** 2747,2783 ****
  	    code = DBX_STATIC_CONST_VAR_CODE;
  	  else
  	    {
- 	      /* Some ports can transform a symbol ref into a label ref,
- 		 because the symbol ref is too far away and has to be
- 		 dumped into a constant pool.  Alternatively, the symbol
- 		 in the constant pool might be referenced by a different
- 		 symbol.  */
- 	      if (GET_CODE (addr) == SYMBOL_REF
- 		  && CONSTANT_POOL_ADDRESS_P (addr))
- 		{
- 		  bool marked;
- 		  rtx tmp = get_pool_constant_mark (addr, &marked);
- 
- 		  if (GET_CODE (tmp) == SYMBOL_REF)
- 		    {
- 		      addr = tmp;
- 		      if (CONSTANT_POOL_ADDRESS_P (addr))
- 		        get_pool_constant_mark (addr, &marked);
- 		      else
- 			marked = true;
- 		    }
- 		  else if (GET_CODE (tmp) == LABEL_REF)
- 		    {
- 		      addr = tmp;
- 		      marked = true;
- 		    }
- 
- 		   /* If all references to the constant pool were optimized
- 		      out, we just ignore the symbol.  */
- 		  if (!marked)
- 		    return 0;
- 		}
- 
  	      /* Ultrix `as' seems to need this.  */
  #ifdef DBX_STATIC_STAB_DATA_SECTION
  	      data_section ();
--- 2778,2783 ----
*** /dev/null	Tue Oct 26 21:02:43 2004
--- gcc/testsuite/gcc.dg/20041216-1.c	Thu Dec 16 20:42:06 2004
***************
*** 0 ****
--- 1,23 ----
+ /* This test case would get an unresolved symbol during link
+    because stabs referred to an optimized-away literal pool
+    entry.  */
+ 
+ /* { dg-do run { target s390*-*-* } } */
+ /* { dg-options "-O2 -fno-omit-frame-pointer -gstabs" } */
+ 
+ int main (void)
+ {
+   static char buf[4096];
+   char *p;
+ 
+   do
+     {
+       p = buf;
+       asm volatile ("" : : : "memory", "0", "1", "2", "3", "4", "5", "6",
+ 				       "7", "8", "9", "10", "12");
+     }
+   while (*p);
+ 
+   return 0;
+ }
+ 
-- 
  Dr. Ulrich Weigand
  Linux on zSeries Development
  Ulrich.Weigand@de.ibm.com


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