Re: [PATCH] PR symtab/1651: core dump reading xlc compiled binaries

[Elena Zannoni <ezannoni@redhat.com>]

Roger Sayle writes:

 > 
 > Firstly, in scan_xcoff_symtab to handle continuation symbols, the
 > code calls next_symbol_text, which is a macro that invokes the function
 > pointer next_symbol_text_func.  Unfortunately, in xcoffread.c, this
 > variable, next_symbol_text_func, is only initialized (to
 > xcoff_next_symbol_text) in xcoff_psymtab_to_symtab which isn't executed
 > prior to the failure when reading xlc generated binaries.
 > 
 > The possible solutions to this first issue are to either initialize
 > next_symbol_text_func earlier (perhaps at the top of scan_xcoff_symtab),
 > or alternatively, as implemented below, bypass the virtual dispatch
 > inside xcoffread.c, and instead call xcoff_next_symbol_text directly.

I prefer to use the other approach, which is also used in
dbxread.c. I'll change your patch accordingly. Please verify that it
still fixes your problem.

 > 
 > Secondly, in xcoff_next_symbol_text, there's already a FIXME at the
 > top of the function about how it ignores it's objfile argument and
 > instead uses this_symtab_psymtab->objfile instead.  As mentioned above,
 > this function can now be called for "symbtab" symbols in addition to
 > "psymtab" symbols, so in the case of this failure this_symtab_psymtab
 > is NULL when we invoke this function.  The least intrusive fix to this
 > problem is to only overwrite objfile when this_symtab_psymtab is non-NULL.
 > An alternative fix might be to always use the objfile argument as
 > specified by the caller.  I wasn't confident enough to risk this.
 > 

Agreed.

 > With these two tweaks, I was able to get gdb to read in an debug the
 > xlc-compiled cc1 binary from mainline GCC.
 > 
 > 
 > The following patch has been tested on powerpc-ibm-aix5.2.0.0 by
 > building "gdb" from CVS (6.3.50_2004_11_20-cvs -nx) configured with
 > "--enable-64-bit-bfd" and running "make check" in the gdb/ directory
 > with no new regressions.  The results seem non-deterministic and
 > I had to run "make check" a second time to get identical results.
 > Searching GDB's GNATS database reveals that this failure is actually
 > PR symtab/1651.  I have absolutely no idea how to write a GDB test
 > case, and I don't have CVS access nor copyright assignments for GDB.
 > Hopefully the changes below should be small enough not to require an
 > assignment as this is my first GDB patch submission.
 > 

Yes, this is fine. 

Here is my version of the patch, let me know if it works for you and
I'll commit it.


Index: xcoffread.c
===================================================================
RCS file: /cvs/src/src/gdb/xcoffread.c,v
retrieving revision 1.44
diff -u -p -r1.44 xcoffread.c
--- xcoffread.c 23 Oct 2004 16:18:09 -0000      1.44
+++ xcoffread.c 29 Nov 2004 02:06:10 -0000
@@ -868,7 +868,8 @@ xcoff_next_symbol_text (struct objfile *
   struct internal_syment symbol;
   char *retval;
   /* FIXME: is this the same as the passed arg? */
-  objfile = this_symtab_psymtab->objfile;
+  if (this_symtab_psymtab)
+    objfile = this_symtab_psymtab->objfile;
  
   bfd_coff_swap_sym_in (objfile->obfd, raw_symbol, &symbol);
   if (symbol.n_zeroes)
@@ -2170,6 +2171,7 @@ scan_xcoff_symtab (struct objfile *objfi
   last_source_file = NULL;
  
   abfd = objfile->obfd;
+  next_symbol_text_func = xcoff_next_symbol_text;
  
   sraw_symbol = ((struct coff_symfile_info *) objfile->deprecated_sym_private)->symtbl;
   nsyms = ((struct coff_symfile_info *) objfile->deprecated_sym_private)->symtbl_num_syms;