This is the mail archive of the gdb-patches@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: [RFA/stabs reader] Fix v3 duplicate constructors problem


Jason Merrill writes:
> The thing is, we want the debugger to treat them as the same function, so
> that setting a breakpoint on the signature actually sets one on each and
> the like.

I for one do not want that to happen at all!

There really are two bodies of code in the target program code.
The compiler emits two bodies of code; the linker recognizes two bodies
of code with different names.

Consider this code:

  class C1 { public: C1::C1(); };
  C1::C1 () { foo(); bar(); bletch(); }

Suppose the user sets a breakpoint in foo(), looks at the stack,
and sees the name C1::C1().  They decide they want to read the machine
language instructions for the constructor, so they type "disass C1::C1".
What do you want gdb to do?

I would like gdb to demangle different names differently.  Perhaps:

  (gdb) ptype C1
    ... C1::C1 ...
    ... C1::C1$base ...

... where the first line is for the in-charge constructor, and the second
line is for the not-in-charge constructor.  Then the user can disassemble,
breakpoint, and call whichever function they want (they better know what
they are doing if they call a not-in-charge constructor by hand though).
If they don't know what C1::C1$base is, they can read a document, where
they can learn that each constructor and destructor in the source code is
compiled to multiple object functions in the object code, with different
interfaces and purposes.

As to how this relates onto symbol handling, I don't know.  I just know
that I want names that reflect reality in ptype, disassmble, break,
and backtrace.

Michael C


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