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

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

[Roger Sayle]

Please be gentle, I'm a "gdb-patches" virgin...

The following patch is my proposed solution to GDB's PR symtab/1651.
GCC currently fails to bootstrap on AIX 5.1 hosted from the native
IBM VisualAge compiler xlc; that problem is that the xlc compiler is
miscompiling the stage1 compiler resulting in a comparison failure.
However, in trying to debug the "cc1" executable created by xlc, I
rapidly discovered that gdb immediately dumps core with a segmentation
fault just reading in the xlc-compiled "cc1" binary.

Please forgive the following terminology, I understand very little
about debuggers (except that they shouldn't segfault).  The problem
is that xcoffread isn't prepared to handle the way xlc splits the
debug information for enumerated types in its "symtab".  For cc1,
xlc splits the debug info for enumerated type "insn_code" in the
debug info using XCOFF '?' continuations.  GDB's reader can handle
these, but unfortunately it makes the assumptions that these only
occur in psymtabs, not in symtabs.  This leads to two related logic
errors:

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.

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.

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.

So how did I do?  Ok for mainline?



2004-11-20  Roger Sayle  <roger@eyesopen.com>

	PR symtab/1651
	* xcoffread.c (xcoff_next_symbol_text): Check this_symtab_psymtab
	for NULL before assigning this_symtab_psymtab->objfile to objfile.
	(scan_xcoff_symtab): Call xcoff_next_symbol_text directly instead
	of next_symbol_text as next_symbol_text_func might not be assigned.


Index: xcoffread.c
===================================================================
RCS file: /cvs/src/src/gdb/xcoffread.c,v
retrieving revision 1.44
diff -c -3 -p -r1.44 xcoffread.c
*** xcoffread.c	23 Oct 2004 16:18:09 -0000	1.44
--- xcoffread.c	20 Nov 2004 23:29:18 -0000
*************** xcoff_next_symbol_text (struct objfile *
*** 868,874 ****
    struct internal_syment symbol;
    char *retval;
    /* FIXME: is this the same as the passed arg? */
!   objfile = this_symtab_psymtab->objfile;

    bfd_coff_swap_sym_in (objfile->obfd, raw_symbol, &symbol);
    if (symbol.n_zeroes)
--- 868,875 ----
    struct internal_syment symbol;
    char *retval;
    /* FIXME: is this the same as the passed arg? */
!   if (this_symtab_psymtab)
!     objfile = this_symtab_psymtab->objfile;

    bfd_coff_swap_sym_in (objfile->obfd, raw_symbol, &symbol);
    if (symbol.n_zeroes)
*************** scan_xcoff_symtab (struct objfile *objfi
*** 2691,2697 ****
  			/* Check for and handle cretinous dbx symbol name
  			   continuation!  */
  			if (*p == '\\' || (*p == '?' && p[1] == '\0'))
! 			  p = next_symbol_text (objfile);

  			/* Point to the character after the name
  			   of the enum constant.  */
--- 2692,2698 ----
  			/* Check for and handle cretinous dbx symbol name
  			   continuation!  */
  			if (*p == '\\' || (*p == '?' && p[1] == '\0'))
! 			  p = xcoff_next_symbol_text (objfile);

  			/* Point to the character after the name
  			   of the enum constant.  */

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833

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

[Elena Zannoni]

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;

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

[Roger Sayle]

On Sun, 28 Nov 2004, Elena Zannoni wrote:
> Here is my version of the patch, let me know if it works for you and
> I'll commit it.

Many thanks.  I can confirm that your patch fixes the segmentation fault
loading an xlc-compiled gcc/cc1 on powerpc-ibm-aix5.2.0.0 when applied
to gdb 6.3.50_2004-11-29-cvs.

Thanks again,

Roger
--

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

[Roger Sayle]

On Sun, 28 Nov 2004, Elena Zannoni wrote:
> 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.
>
> Here is my version of the patch, let me know if it works for you and
> I'll commit it.

Hi Elena,

Has there been any movement on this?  Its been nearly three weeks since
I confirmed that your version of the patch resolves the GDB segmentation
fault on AIX, but a fix still hasn't been committed to CVS.

Thanks again for your help getting this resolved,

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833

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

[Roger Sayle]

Dear Elena,

I don't want to appear pushy, but it's now been three months since
you agreed to commit a variant of my patch to resolve GDB PR symtab/1651.
http://sources.redhat.com/ml/gdb-patches/2004-11/msg00499.html

The original patch itself was posted here:
http://sources.redhat.com/ml/gdb-patches/2004-11/msg00422.html


Any chance that I could ask you whether you still intend to apply
your version of this change?  I suspect that its just slipped your
mind and fallen slipped through the cracks.  Otherwise, let me (or
another gdb maintainer) know if you can't, so that we can make some
progress to getting this issue resolved.

I was worried for while that something terrible had happened to
you, but your recent activity on CIA reveals you're alive and well,
even though you hadn't previously committed anything to gdb's CVS
since April last year:  http://cia.navi.cx/stats/author/ezannoni

Thanks in advance,

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833