This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] PR symtab/1651: core dump reading xlc compiled binaries
- From: Elena Zannoni <ezannoni at redhat dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Sun, 28 Nov 2004 21:07:34 -0500
- Subject: Re: [PATCH] PR symtab/1651: core dump reading xlc compiled binaries
- References: <Pine.LNX.4.44.0411201714190.9253-100000@www.eyesopen.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;