dwarf2 symtab bfd_section corrupt?

dwarf2 symtab bfd_section corrupt?

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

Hello,

Both the symtab and psymtab objects contain the common entry `asection 
*bfd_section'.  One field of the BFD section is it's `struct bfd *owner' 
- the object file that contains the section.

The new dwarf2loc stuff extends the symtab object adding a `struct 
objfile *objfile' field.  An objfile contains the field `struct bfd *obfd'.

Hmm, looks like redundant information.  Why not just point the 
symtab/psymtab at the obj_section?

The attached patch adds an assert to check the theory out.  It fails. 
The bfd_section ends up pointing at the file "libc.so"!

Andrew

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 2165 bytes --]

? diffs
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.3867
diff -u -r1.3867 ChangeLog
--- ChangeLog	23 Feb 2003 20:24:16 -0000	1.3867
+++ ChangeLog	2 Mar 2003 16:48:22 -0000
@@ -1,3 +1,10 @@
+2003-02-24  Andrew Cagney  <cagney@redhat.com>
+
+	* dwarf2loc.c: Include "gdb_assert.h".
+	(locexpr_read_variable): Assert that the symbol and locexp have
+	identical BFDs.
+	(locexpr_read_needs_frame, locexpr_describe_location): Ditto.
+
 2003-02-23  Stephane Carrez  <stcarrez@nerim.fr>
 
 	* m68hc11-tdep.c (m68hc11_gdbarch_init): long double is 64-bit wide.
Index: dwarf2loc.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2loc.c,v
retrieving revision 1.1
diff -u -r1.1 dwarf2loc.c
--- dwarf2loc.c	21 Feb 2003 15:24:17 -0000	1.1
+++ dwarf2loc.c	2 Mar 2003 16:48:23 -0000
@@ -31,6 +31,8 @@
 #include "dwarf2expr.h"
 #include "dwarf2loc.h"
 
+#include "objfiles.h"
+#include "gdb_assert.h"
 #include "gdb_string.h"
 
 #ifndef DWARF2_REG_TO_REGNUM
@@ -241,6 +243,8 @@
 {
   struct dwarf2_locexpr_baton *dlbaton = SYMBOL_LOCATION_BATON (symbol);
   struct value *val;
+  gdb_assert (SYMBOL_BFD_SECTION (symbol) == NULL
+	      || SYMBOL_BFD_SECTION (symbol)->owner == dlbaton->objfile->obfd);
   val = dwarf2_evaluate_loc_desc (symbol, frame, dlbaton->data, dlbaton->size,
 				  dlbaton->objfile);
 
@@ -252,6 +256,8 @@
 locexpr_read_needs_frame (struct symbol *symbol)
 {
   struct dwarf2_locexpr_baton *dlbaton = SYMBOL_LOCATION_BATON (symbol);
+  gdb_assert (SYMBOL_BFD_SECTION (symbol) == NULL
+	      || SYMBOL_BFD_SECTION (symbol)->owner == dlbaton->objfile->obfd);
   return dwarf2_loc_desc_needs_frame (dlbaton->data, dlbaton->size);
 }
 
@@ -261,7 +267,8 @@
 {
   /* FIXME: be more extensive.  */
   struct dwarf2_locexpr_baton *dlbaton = SYMBOL_LOCATION_BATON (symbol);
-
+  gdb_assert (SYMBOL_BFD_SECTION (symbol) == NULL
+	      || SYMBOL_BFD_SECTION (symbol)->owner == dlbaton->objfile->obfd);
   if (dlbaton->size == 1
       && dlbaton->data[0] >= DW_OP_reg0
       && dlbaton->data[0] <= DW_OP_reg31)

Re: dwarf2 symtab bfd_section corrupt?

[Daniel Jacobowitz]

On Sun, Mar 02, 2003 at 12:54:10PM -0500, Andrew Cagney wrote:
> Hello,
> 
> Both the symtab and psymtab objects contain the common entry `asection 
> *bfd_section'.  One field of the BFD section is it's `struct bfd *owner' 
> - the object file that contains the section.
> 
> The new dwarf2loc stuff extends the symtab object adding a `struct 
> objfile *objfile' field.  An objfile contains the field `struct bfd *obfd'.
> 
> Hmm, looks like redundant information.  Why not just point the 
> symtab/psymtab at the obj_section?
> 
> The attached patch adds an assert to check the theory out.  It fails. 
> The bfd_section ends up pointing at the file "libc.so"!
> 
> Andrew

Well now, isn't _that_ interesting.  Here's the problem:
symtab.c:fixup_section sets the BFD_SECTION of a symbol based on doing
a minsym lookup, which assumes a 1-1 correspondence.  The first crash I
see in the testsuite is for a variable named f3, which happens to occur
in the debug info for libm.  This is in call-rt-st.

Something's wrong here; f3 is really a stack local.  It shouldn't have
a SYMBOL_BFD_SECTION.  Even if it did we should be setting based on an
address->section mapping, not by a name-based minsym lookup, I think.
I have no idea how that would work with, say, overlays though.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer