public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* [crash] Section index is uninitialized
@ 2000-11-30 17:41 Richard Henderson
  2000-11-30 20:36 ` Daniel Berlin
  0 siblings, 1 reply; 6+ messages in thread
From: Richard Henderson @ 2000-11-30 17:41 UTC (permalink / raw)
  To: gdb

I can provide the binary on request if anyone is curious to poke
at it.  It is a c++ testsuite test case created by today's cvs gcc.

Any hints on finding the problem?


r~



(top-gdb) run ./z
Starting program: /castro/street/rth/binu/build/axp/gdb/./gdb ./z
During symbol reading, register number 312 too large (max 66) in symbol buf.
During symbol reading, PDR for _start, but no symbol.
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "alphaev6-unknown-linux-gnu"...
Setting up the environment for debugging gdb.
.gdbinit:5: Error in sourced command file:
Function "internal_error" not defined.
(gdb) run
Starting program: /castro/street/rth/binu/build/axp/gdb/./z 
During symbol reading, register number 312 too large (max 66) in symbol buf.
During symbol reading, PDR for _start, but no symbol.
During symbol reading, type qualifier 'const' ignored.

Breakpoint 1, internal_error (
    string=0x12025f387 "Section index is uninitialized")
    at ../../../src/gdb/utils.c:734
734	  va_start (ap, string);
(top-gdb) up
#1  0x12016c770 in new_symbol (die=0x1204af6e0, type=0x0, objfile=0x120307dd0, 
    cu_header=0x11fffebb8) at ../../../src/gdb/dwarf2read.c:4184
4184			      SYMBOL_VALUE_ADDRESS (sym) +=
(top-gdb) p *sym
$1 = {ginfo = {name = 0x1206e18f0 "_ZTIP1D", value = {ivalue = 4831863968, 
      block = 0x1200064a0, bytes = 0x1200064a0 "\206\002", 
      address = 4831863968, chain = 0x1200064a0}, language_specific = {
      cplus_specific = {demangled_name = 0x0}, chill_specific = {
        demangled_name = 0x0}}, language = language_cplus, section = -1, 
    bfd_section = 0x120304400}, type = 0x1206e2a48, namespace = VAR_NAMESPACE, 
  aclass = LOC_STATIC, line = 0, aux_value = {basereg = 0}, aliases = 0x0, 
  ranges = 0x0}
(top-gdb) p *sym->ginfo.bfd_section
$2 = {name = 0x120301188 ".rodata", id = 64, index = 14, next = 0x120304660, 
  flags = 595, user_set_vma = 1, reloc_done = 0, linker_mark = 0, gc_mark = 0, 
  segment_mark = 0, vma = 4831863952, lma = 4831863952, _cooked_size = 1638, 
  _raw_size = 1638, output_offset = 0, output_section = 0x0, 
  alignment_power = 4, relocation = 0x0, orelocation = 0x0, reloc_count = 0, 
  filepos = 25744, rel_filepos = 0, line_filepos = 0, userdata = 0x0, 
  contents = 0x0, lineno = 0x0, lineno_count = 0, comdat = 0x0, 
  kept_section = 0x0, moving_line_filepos = 0, target_index = 0, 
  used_by_bfd = 0x120304560, constructor_chain = 0x0, owner = 0x120300a60, 
  symbol = 0x120304500, symbol_ptr_ptr = 0x1203044e0, link_order_head = 0x0, 
  link_order_tail = 0x0}

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [crash] Section index is uninitialized
  2000-11-30 17:41 [crash] Section index is uninitialized Richard Henderson
@ 2000-11-30 20:36 ` Daniel Berlin
  2000-11-30 21:41   ` Kevin Buettner
  0 siblings, 1 reply; 6+ messages in thread
From: Daniel Berlin @ 2000-11-30 20:36 UTC (permalink / raw)
  To: Richard Henderson; +Cc: gdb

Richard Henderson <rth@redhat.com> writes:

> I can provide the binary on request if anyone is curious to poke
> at it.  It is a c++ testsuite test case created by today's cvs gcc.
> 
> Any hints on finding the problem?

No, but i'm positive it's not a mangling problem.
I have a 4 liner patch to libiberty to make it detect the new abi
names and demangle them when AUTO_DEMANGLING is set (our default for
GDB), and it properly demangles them.

This is caused by something else.
I've highlighted the exact cause below:

> 
> r~
> 
> (top-gdb) run ./z
> Starting program: /castro/street/rth/binu/build/axp/gdb/./gdb ./z
> During symbol reading, register number 312 too large (max 66) in symbol buf.
> During symbol reading, PDR for _start, but no symbol.
> GNU gdb 5.0
> Copyright 2000 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "alphaev6-unknown-linux-gnu"...
> Setting up the environment for debugging gdb.
> .gdbinit:5: Error in sourced command file:
> Function "internal_error" not defined.
> (gdb) run
> Starting program: /castro/street/rth/binu/build/axp/gdb/./z 
> During symbol reading, register number 312 too large (max 66) in symbol buf.
> During symbol reading, PDR for _start, but no symbol.
> During symbol reading, type qualifier 'const' ignored.
> 
> Breakpoint 1, internal_error (
>     string=0x12025f387 "Section index is uninitialized")
>     at ../../../src/gdb/utils.c:734
> 734	  va_start (ap, string);
> (top-gdb) up
> #1  0x12016c770 in new_symbol (die=0x1204af6e0, type=0x0, objfile=0x120307dd0, 
>     cu_header=0x11fffebb8) at ../../../src/gdb/dwarf2read.c:4184
> 4184			      SYMBOL_VALUE_ADDRESS (sym) +=
> (top-gdb) p *sym
> $1 = {ginfo = {name = 0x1206e18f0 "_ZTIP1D", value = {ivalue = 4831863968, 
>       block = 0x1200064a0, bytes = 0x1200064a0 "\206\002", 
>       address = 4831863968, chain = 0x1200064a0}, language_specific = {
>       cplus_specific = {demangled_name = 0x0}, chill_specific = {
>         demangled_name = 0x0}}, language = language_cplus, section =-1,                                                                       ^^

That's the problem.
Why it happens, no idea.

If it helps, Kevin, we never set SYMBOL_SECTION in dwarf2read.

Should we be setting it?
We set it in stabsread.

--Dan

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [crash] Section index is uninitialized
  2000-11-30 20:36 ` Daniel Berlin
@ 2000-11-30 21:41   ` Kevin Buettner
  2000-11-30 23:26     ` Richard Henderson
  0 siblings, 1 reply; 6+ messages in thread
From: Kevin Buettner @ 2000-11-30 21:41 UTC (permalink / raw)
  To: Daniel Berlin, Richard Henderson; +Cc: gdb

On Nov 30, 11:36pm, Daniel Berlin wrote:

> > 4184			      SYMBOL_VALUE_ADDRESS (sym) +=
> > (top-gdb) p *sym
> > $1 = {ginfo = {name = 0x1206e18f0 "_ZTIP1D", value = {ivalue = 4831863968, 
> >       block = 0x1200064a0, bytes = 0x1200064a0 "\206\002", 
> >       address = 4831863968, chain = 0x1200064a0}, language_specific = {
> >       cplus_specific = {demangled_name = 0x0}, chill_specific = {
> >         demangled_name = 0x0}}, language = language_cplus, section =-1,                                                                       ^^
> 
> That's the problem.
> Why it happens, no idea.
> 
> If it helps, Kevin, we never set SYMBOL_SECTION in dwarf2read.
> 
> Should we be setting it?
> We set it in stabsread.

The call to fixup_symbol_section() (which is one line before the line
indicated above) should be setting section to the section associated
with the minimal symbol.  I think we need to find out why
fixup_symbol_section() is failing to do this.  (Obviously, it could be
failing if if fails to locate the minimal symbol.  If this is the
case, we need to find out if symbol simply doesn't exist in the minimal
symbol table or if it's a demangling problem...  Or possibly there's
another reason why the symbol wouldn't be found.)

Kevin

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [crash] Section index is uninitialized
  2000-11-30 21:41   ` Kevin Buettner
@ 2000-11-30 23:26     ` Richard Henderson
  2000-12-01  0:51       ` Kevin Buettner
  0 siblings, 1 reply; 6+ messages in thread
From: Richard Henderson @ 2000-11-30 23:26 UTC (permalink / raw)
  To: Kevin Buettner; +Cc: Daniel Berlin, gdb

On Thu, Nov 30, 2000 at 10:40:52PM -0700, Kevin Buettner wrote:
> The call to fixup_symbol_section() (which is one line before the line
> indicated above) should be setting section to the section associated
> with the minimal symbol.  I think we need to find out why
> fixup_symbol_section() is failing to do this.

Turns out to be more convoluted than that.  fixup_symbol_section
is setting the section to that of the minimal symbol.  It's just
that that is -1 as well.

More pointers?  Or, if you like, ~rth/gdb-killer in Sunnyvale.


r~

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [crash] Section index is uninitialized
  2000-11-30 23:26     ` Richard Henderson
@ 2000-12-01  0:51       ` Kevin Buettner
  2000-12-01  1:35         ` Richard Henderson
  0 siblings, 1 reply; 6+ messages in thread
From: Kevin Buettner @ 2000-12-01  0:51 UTC (permalink / raw)
  To: Richard Henderson; +Cc: Daniel Berlin, gdb

On Nov 30, 11:26pm, Richard Henderson wrote:

> On Thu, Nov 30, 2000 at 10:40:52PM -0700, Kevin Buettner wrote:
> > The call to fixup_symbol_section() (which is one line before the line
> > indicated above) should be setting section to the section associated
> > with the minimal symbol.  I think we need to find out why
> > fixup_symbol_section() is failing to do this.
> 
> Turns out to be more convoluted than that.  fixup_symbol_section
> is setting the section to that of the minimal symbol.  It's just
> that that is -1 as well.
> 
> More pointers?  Or, if you like, ~rth/gdb-killer in Sunnyvale.

Try the following patch...

	* elfread.c (record_minimal_symbol_and_info): Don't guess
	at the section index to use; just use bfd's index.

Index: elfread.c
===================================================================
RCS file: /cvs/src/src/gdb/elfread.c,v
retrieving revision 1.11
diff -u -p -r1.11 elfread.c
--- elfread.c	2000/08/07 15:02:48	1.11
+++ elfread.c	2000/12/01 08:45:34
@@ -171,32 +171,13 @@ record_minimal_symbol_and_info (char *na
 				enum minimal_symbol_type ms_type, char *info,	/* FIXME, is this really char *? */
 				asection *bfd_section, struct objfile *objfile)
 {
-  int section;
-
-  /* Guess the section from the type.  This is likely to be wrong in
-     some cases.  */
-  switch (ms_type)
-    {
-    case mst_text:
-    case mst_file_text:
-      section = bfd_section->index;
 #ifdef SMASH_TEXT_ADDRESS
-      SMASH_TEXT_ADDRESS (address);
+  if (ms_type == mst_text || ms_type == mst_file_text)
+    SMASH_TEXT_ADDRESS (address);
 #endif
-      break;
-    case mst_data:
-    case mst_file_data:
-    case mst_bss:
-    case mst_file_bss:
-      section = bfd_section->index;
-      break;
-    default:
-      section = -1;
-      break;
-    }
 
   return prim_record_minimal_symbol_and_info
-    (name, address, ms_type, info, section, bfd_section, objfile);
+    (name, address, ms_type, info, bfd_section->index, bfd_section, objfile);
 }
 
 /*

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [crash] Section index is uninitialized
  2000-12-01  0:51       ` Kevin Buettner
@ 2000-12-01  1:35         ` Richard Henderson
  0 siblings, 0 replies; 6+ messages in thread
From: Richard Henderson @ 2000-12-01  1:35 UTC (permalink / raw)
  To: Kevin Buettner; +Cc: Daniel Berlin, gdb

On Fri, Dec 01, 2000 at 01:51:35AM -0700, Kevin Buettner wrote:
> 	* elfread.c (record_minimal_symbol_and_info): Don't guess
> 	at the section index to use; just use bfd's index.

That did it.  Thanks.


r~

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2000-12-01  1:35 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-11-30 17:41 [crash] Section index is uninitialized Richard Henderson
2000-11-30 20:36 ` Daniel Berlin
2000-11-30 21:41   ` Kevin Buettner
2000-11-30 23:26     ` Richard Henderson
2000-12-01  0:51       ` Kevin Buettner
2000-12-01  1:35         ` Richard Henderson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).