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: C++/Java regressions


Hi Ian,

> I have probably lost the context of the question.  I am only talking
> about the case where DMGL_PARAMS is not passed.  In that case, the
> demangler will indeed print `Foo::method' for both of your examples.
> For that matter, it will also print `Foo::method' for `int method
> (int);'.

Ah, sorry, I am not providing enough context.

The context is this kind of message from gdb:

  (gdb) continue
  Continuing.

  Breakpoint 3, A::bar(int) const (this=0xbffff770, arg=15) at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/testsuite/gdb.cp/method.cc:44

(This output is from the old demangler).

gdb wants to print a nice message showing the name of the function and
its arguments.  That's why gdb calls the demangler without DMGL_PARAMS
and then writes its own paramater list.  But then that raises the
question of where the "const" goes.

The delicate part is that gdb doesn't mind losing the params,
because gdb is going to print the params itself manually.  But I
do mind losing the "const" because gdb doesn't print its own "const".

> I think that is appropriate.  Without DMGL_PARAMS, you can't
> distinguish any Foo::method overloaded based on parameter types.  So
> it seems logical to me that you also shouldn't be able to distinguish
> overloading based on the method qualifier.  And that is how the V2
> demangler behaved when DMGL_PARAMS was not passed.
> 
> Does that make sense?

Totally.

I think the real issue is that us gdb folks need to sit down with some
use cases and figure out what we want to print in all situations.  Then
translate that down to requests for enhanced demangler API's.  But it's
lame of me to ask "can you tweak the demangler to produce one string
that co-incidentally looks nice for us".  In a case like the above, I
think gdb really wants some kind of structured return value, and then
gdb can assemble the pieces any way it wants.

For now, I will be happy if the new demangler has no regressions
compared to the old demangler.  And the new demangler already has
at least one bug fix shown by the gdb test suite.  We can come back
with our structured API request when we are ready.

Michael C


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