This is the mail archive of the gdb@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]

Re: adding namespace support to GDB


In article <20020823184746.GA25528@nevyn.them.org>, Daniel Jacobowitz
<drow@mvista.com> writes:
> On Fri, Aug 23, 2002 at 11:41:06AM -0700, David Carlton wrote:

>> Certainly it seems like a solution for C++ will initially have to
>> get recreate namespace info from DW_AT_MIPS_linkage_name, and
>> there's no way that we'll be able to allow users to use symbol
>> names as if all the appropriate using directives were in effect,
>> since that information simply isn't in the debug information that
>> GCC is currently producing.

> C++ certainly does _not_ need to reconstruct from
> DW_AT_MIPS_linkage_name.  Everything we need should be there in
> DW_TAG_namespace and DW_TAG_structure/class markers; I have patches
> to use this information, with the caveats I noted in my other
> message.

Sure, if the file being debugged is appropriately tagged with
DW_TAG_namespace.  (And, of course, with DW_TAG_structure/class_type,
and other compound data structures; currently, GCC generates
DW_TAG_structure_type instead of DW_TAG_class_type, but I don't think
that should have much of a practical effect on GDB.)

But we can't refuse to debug C++ code that was produced by a version
of GCC that doesn't generate those tags.  And, right now, the only way
we can get an approximation to namespace information is by looking at
the contents of DW_AT_MIPS_linkage_name.  There are still flaws with
that other than not seeing using directives - e.g. I don't think
there's any way to tell what namespace an enum lives in from the
information that GCC currently produces - but it's a start.

> I am gradually working on removing all uses of the physname from the
> C++ debugging code.  It's a hack (and a space waste!).

Right.  I'm not suggesting that we keep the physnames around
indefinitely.  There's information in DW_AT_MIPS_linkage_name that I
think we need currently, but that doesn't mean that we can't discard
it after using it.  E.g. it makes sense to me that, if GDB runs into a
class declaration, it would grab the DW_AT_MIPS_linkage_name of its
first member, demangle it and figure out where in the namespace
hierarchy the class under investigation lives, and then keep that
information around; once it's done that, it doesn't need to use the
DW_AT_MIPS_linkage_name of any of the other members, let alone keep
them around indefinitely.

David Carlton
carlton@math.stanford.edu


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]