This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[patch] Removal of the FIND_PC_SECT_PSYMTAB search [Re: [patch] Discontiguous PSYMTABs]
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: gdb-patches at sources dot redhat dot com
- Cc: Daniel Jacobowitz <drow at false dot org>, Jim Blandy <jimb at codesourcery dot com>, Vladimir Prus <ghost at cs dot msu dot su>
- Date: Sun, 9 Dec 2007 21:40:03 +0100
- Subject: [patch] Removal of the FIND_PC_SECT_PSYMTAB search [Re: [patch] Discontiguous PSYMTABs]
- References: <20071009180246.GA26829@host0.dyn.jankratochvil.net> <20071009181701.GA30757@caradoc.them.org> <20071009185434.GA27810@host0.dyn.jankratochvil.net> <20071009185931.GA1220@caradoc.them.org> <20071124154339.GA14913@host0.dyn.jankratochvil.net> <E1Iy0Vd-0006lL-64@zigzag.lvk.cs.msu.su> <20071130111021.GA17867@host0.dyn.jankratochvil.net> <20071130145613.GA5941@caradoc.them.org> <20071209203138.GA23339@host0.dyn.jankratochvil.net>
On Sun, 09 Dec 2007 21:31:38 +0100, Jan Kratochvil wrote:
...
> Attaching the fix for discontiguous psymtabs based on the addrmap framework.
...
> #2 My folowup mail will offer a future removal of FIND_PC_SECT_PSYMTAB_IS_VALID.
This is the promised simplification. It has no testsuite regressions on x86_64
GNU/Linux but I feel such test is not sufficient.
I guess the heuristic complicated search there was just to deal with
overlapping PSYMTABs - these are now solved the clean way by ADDRMAP.
But some compilers may not produce the right CU DW_AT_ranges and/or the debug
info formats may not support it, I do not know.
Regards,
Jan
2007-12-09 Jan Kratochvil <jan.kratochvil@redhat.com>
* symtab.c (find_pc_sect_psymtab_is_valid): Remoev the function.
(find_pc_sect_psymtab): Remove the FIND_PC_SECT_PSYMTAB_IS_VALID call,
assume the found PSYMTAB is always valid.
diff -u -rup gdb-addrmap-conservative/symtab.c gdb/symtab.c
--- ./gdb-addrmap-conservative/symtab.c 2007-12-09 17:59:30.000000000 +0100
+++ ./gdb/symtab.c 2007-12-09 20:42:33.000000000 +0100
@@ -760,83 +760,6 @@ matching_bfd_sections (asection *first,
return 0;
}
-/* Find which partial symtab contains PC and SECTION starting at psymtab PST.
- We may find a different psymtab than PST. See FIND_PC_SECT_PSYMTAB. */
-
-struct partial_symtab *
-find_pc_sect_psymtab_is_valid (CORE_ADDR pc, asection *section,
- struct partial_symtab *pst,
- struct minimal_symbol *msymbol)
-{
- struct objfile *objfile = pst->objfile;
- struct partial_symtab *tpst;
- struct partial_symtab *best_pst = pst;
- CORE_ADDR best_addr = pst->textlow;
-
- /* An objfile that has its functions reordered might have
- many partial symbol tables containing the PC, but
- we want the partial symbol table that contains the
- function containing the PC. */
- if (!(objfile->flags & OBJF_REORDERED) &&
- section == 0) /* can't validate section this way */
- return pst;
-
- if (msymbol == NULL)
- return (pst);
-
- /* The code range of partial symtabs sometimes overlap, so, in
- the loop below, we need to check all partial symtabs and
- find the one that fits better for the given PC address. We
- select the partial symtab that contains a symbol whose
- address is closest to the PC address. By closest we mean
- that find_pc_sect_symbol returns the symbol with address
- that is closest and still less than the given PC. */
- for (tpst = pst; tpst != NULL; tpst = tpst->next)
- {
- if (pc >= tpst->textlow && pc < tpst->texthigh)
- {
- struct partial_symbol *p;
- CORE_ADDR this_addr;
-
- /* NOTE: This assumes that every psymbol has a
- corresponding msymbol, which is not necessarily
- true; the debug info might be much richer than the
- object's symbol table. */
- p = find_pc_sect_psymbol (tpst, pc, section);
- if (p != NULL
- && SYMBOL_VALUE_ADDRESS (p)
- == SYMBOL_VALUE_ADDRESS (msymbol))
- return tpst;
-
- /* Also accept the textlow value of a psymtab as a
- "symbol", to provide some support for partial
- symbol tables with line information but no debug
- symbols (e.g. those produced by an assembler). */
- if (p != NULL)
- this_addr = SYMBOL_VALUE_ADDRESS (p);
- else
- this_addr = tpst->textlow;
-
- /* Check whether it is closer than our current
- BEST_ADDR. Since this symbol address is
- necessarily lower or equal to PC, the symbol closer
- to PC is the symbol which address is the highest.
- This way we return the psymtab which contains such
- best match symbol. This can help in cases where the
- symbol information/debuginfo is not complete, like
- for instance on IRIX6 with gcc, where no debug info
- is emitted for statics. (See also the nodebug.exp
- testcase.) */
- if (this_addr > best_addr)
- {
- best_addr = this_addr;
- best_pst = tpst;
- }
- }
- }
- return best_pst;
-}
-
/* Find which partial symtab contains PC and SECTION. Return 0 if
none. We return the psymtab that contains a symbol whose address
exactly matches PC, or, if we cannot find an exact match, the
@@ -867,14 +790,7 @@ find_pc_sect_psymtab (CORE_ADDR pc, asec
pst = addrmap_find (objfile->psymtabs_addrmap, pc);
if (pst != NULL)
- {
- struct partial_symtab *best_pst;
-
- best_pst = find_pc_sect_psymtab_is_valid (pc, section, pst,
- msymbol);
- if (best_pst != NULL)
- return best_pst;
- }
+ return pst;
/* Existing PSYMTABS_ADDRMAP should cover all the PSYMTABS of
OBJFILE, there is no need to scan the remaining ones by hand. */
}
@@ -884,14 +800,7 @@ find_pc_sect_psymtab (CORE_ADDR pc, asec
ALL_OBJFILE_PSYMTABS (objfile, pst)
if (pc >= pst->textlow && pc < pst->texthigh)
- {
- struct partial_symtab *best_pst;
-
- best_pst = find_pc_sect_psymtab_is_valid (pc, section, pst,
- msymbol);
- if (best_pst != NULL)
- return best_pst;
- }
+ return pst;
}
}