This is the mail archive of the gdb@sourceware.org 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: MI Interface and Pretty Print to_string() result


>>>>> "Jens" == Elmenthaler, Jens <jens.elmenthaler@verigy.com> writes:

Jens> - determine address and size of the value, most notably, to create
Jens> a watchpoint from it. Well, here a new MI command would indeed
Jens> help. In order to determine address and size, the CDT builds new
Jens> expressions from the value (i.e. "&(value-expression)" and
Jens> "sizeof(value-expression)"), and calls
Jens> -data-evaluate-expression. This is what is no longer possible with
Jens> children of dynamic variable objects.

Thanks, this is very helpful.

In many cases we could extract the address of a child value.  This can
be done whenever the printer returns a Value object that was taken from
memory somewhere.

Another issue with -var-info-path-expression that I remembered is that
some of the expressions that we would want to return would actually be
unparseble by any gdb older than CVS HEAD.  At least, the libstdc++
printers do casts to qualified pointer types, which were broken.  We may
even need Keith's expr-cumulative merge to handle everything properly; I
am not sure.

Jens> For this, it would be sufficient, if gdb would map "v.[0]" to the
Jens> child named "[0]". The pretty printers children() method provides
Jens> all information that is need. The relative expression of a child
Jens> to it's parent simple is the name of the child. The expressions
Jens> resulting from it don't look like real C/C++ anymore, but this is
Jens> something a user could possibly deal with. In the worst case, a
Jens> gdb frontend could polish that up by using the disply hint
Jens> information.

Changing gdb to treat varobj names specially in an expression is
probably difficult.  I'm not sure it is wise, either.

Having the printers emit "proper" expressions would also be nice... but
this also runs afoul of other gdb expression bugs.  In C++ in particular
there are a number of unimplemented things.  We're working on those, but
it will be a while before they are all finished.

Tom


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