* gdb.c++/psmang.exp: Doc fix.
This commit is contained in:
parent
f5dcdefd1b
commit
4c2acfeafe
@ -1,5 +1,7 @@
|
||||
2002-12-21 Jim Blandy <jimb@redhat.com>
|
||||
|
||||
* gdb.c++/psmang.exp: Doc fix.
|
||||
|
||||
* gdb.c++/psmang.exp, gdb.c++/psmang1.cc, gdb.c++/psmang2.cc: New
|
||||
test.
|
||||
|
||||
|
@ -48,6 +48,8 @@
|
||||
# Breakpoint 1 at 0x804841b: file psmang1.cc, line 13.
|
||||
# (gdb)
|
||||
#
|
||||
# We observed this bug first using Stabs, and then using Dwarf 2.
|
||||
#
|
||||
# The problem was in lookup_symbol_aux: when looking up s::method1, it
|
||||
# would fail to find it in any symtabs, find the minsym with the
|
||||
# corresponding mangled name (say, `_ZN1S7method1Ev'), pass the
|
||||
@ -118,6 +120,14 @@
|
||||
# Note that #including any header file at all into both compilation
|
||||
# units --- say, <stdio.h> --- could create this sort of dependency.
|
||||
#
|
||||
# This is the aspect of the test which the debug format is most likely
|
||||
# to affect, I think. The different formats create different kinds of
|
||||
# inter-CU dependencies, which could mask the bug. It might be
|
||||
# possible for the test to check that at least one of the partial
|
||||
# symtabs remains unread, and fail otherwise --- the failure
|
||||
# indicating that the test itself isn't going to catch the bug it was
|
||||
# meant to, not that GDB is misbehaving.
|
||||
#
|
||||
# Third twist: given the way lookup_block_symbol is written, it's
|
||||
# possible to find the symbol even when it gets passed a mangled name
|
||||
# for its NAME parameter. There are three ways lookup_block_symbol
|
||||
|
Loading…
Reference in New Issue
Block a user