This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hello, I noticed we had a lot of errors like this in the testsuite logs: (gdb) break main warning: (Internal error: pc 0x12000134c in read in psymtab, but not in symtab.) Breakpoint 1 at 0x120001364: file ./gdb.base/advance.c, line 41. The reason for this is the following check in in find_pc_sect_symtab(): fixup_symbol_section (sym, objfile); if (section == SYMBOL_BFD_SECTION (sym)) break; This check makes sure that the symbol section matches the section in which we expect to find the symbol. Unfortunately for us on Tru64, the symbol bfd_section is not set. So we fail the check, and end up discarding the correct symbol table. Then when find_pc_sect_symtab() falls back to searching the partial symtabs, it founds the psymtab corresponding to the symtab we just rejected, and is surprised to see that it has already been read in. ps = find_pc_sect_psymtab (pc, section); if (ps) { if (ps->readin) /* Might want to error() here (in case symtab is corrupt and will cause a core dump), but maybe we can successfully continue, so let's not. */ warning ("\ (Internal error: pc 0x%s in read in psymtab, but not in symtab.)\n", paddr_nz (pc)); s = PSYMTAB_TO_SYMTAB (ps); Investigating the source of the problem showed that symbol bfd_section is not provided by the debugging information, and hence it is retrieved using the minimal symbols through: fixup_symbol_section (sym, objfile); That lead me to find that the bfd_section for the symbols was not set either. The attached patch fixes this. 2004-11-10 Joel Brobecker <brobecker@gnat.com> * mdebugread.c (record_minimal_symbol): New procedure. (parse_partial_symbols): Use record_minimal_symbol to record the new minimal symbols instead of prim_record_minimal_symbol and prim_record_minimal_symbol_and_info. Tested on alpha-tru64, fixes a few hundred regressions. OK to apply? Note that I only modified the code that loads the symbol table from objects generated by GCC. I don't have a DEC C compiler, so I didn't modify the part of parse_partial_symbols that deals with non-gcc symbol tables because I wouldn't be able to test the changes. I can make the changes blindly, but ... Thanks, -- Joel
Attachment:
mdebugread.c.diff
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |