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]

what parts of GDB handle variables with compound names?


Right now, if you're debugging C++ code like this

namespace C {
  int x;
  void f();
}

then, to get at C::x or C::f from within GDB, you usually enclose them
in single quotes.  This (I believe) causes GDB to pretend that you
have a variable whose name is 'C::x' or 'C::f', so lookup_symbol (or
whatever) eventually gets passed that name.

Eventually, it would be desirable for various reasons (including both
cleanliness and correctness) for such lookups to consist of a two-part
process: first look up 'C' to get some sort of namespace object, and
then look up x in the namespace given by C.  This is (I assume!) the
same sort of thing that happens with classes: at some point, you might
call lookup_symbol with "C" as the name and with STRUCT_NAMESPACE as
the namespace, but the resulting symbol would have type
TYPE_CODE_NAMESPACE (or whatever) instead of TYPE_CODE_CLASS.

So my question is: what parts of GDB am I going to have to modify to
do this?  Where are the main areas that I'll have to worry about?  If
I'm a user of GDB who types 'print C::x', then I'll eventually end up
in parse_expression and eval_expression, so I'll have to deal with
this there.  If I'm a user of GDB who types 'break C::f', then I'll
eventually end up in decode_line_1, so I'll have to deal with this
there.  Are there other areas of GDB where I'll have to deal with this
issue?

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]