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: breakpoints in shared libraries


On Tue, Feb 14, 2006 at 06:21:07PM +0100, Mark Kettenis wrote:
> But Florian is setting a breakpoint using FILENAME:LINE syntax and not
> using FUNCTIONNAME syntax.  That should work isn't it?  At least as
> long as GCC is not inlining the constructor such that there are
> actually multiple copies in the code and GDB sets the breakpoint in a
> different copy than the one being executed.

Nope.  I don't have a handy copy of the explanation, so here it is.

Take a look at the "Itanium C++ ABI", which has some Itanium-specific
language in it but is actually widely adopted for non-Itanium platforms
by multiple compilers, GNU and otherwise.  Here it is:

  http://www.codesourcery.com/cxx-abi/abi.html

It's got this to say about constructors:

  <ctor-dtor-name> ::= C1	# complete object constructor
		   ::= C2	# base object constructor
		   ::= C3	# complete object allocating constructor
		   ::= D0	# deleting destructor
		   ::= D1	# complete object destructor
		   ::= D2	# base object destructor

The relevant section is 2.6.  When constructing a virtual base class,
the C2 constructor is called instead of the C1 constructor.

Now, in theory, a compiler can generate one of these as a tiny
trampoline that jumps to the other, and only emit debug information for
the real one, and things will work.  But GCC doesn't do this and
attempts to get it to do so have, so far, met with failure.  So there's
two functions for every single constructor, and GDB tends to breakpoint
one of them more or less at random.

I maintain that the two right things to do here are (A) fix GCC to
support functions with multiple entry points, or at least something
that can give a good impression of it, and (B) set breakpoints by
function name or line number at all copies.

An astute observer will notice that both (A) and (B) are hard :-)
I've been working on (B) as I can find the time, and some cleanups
for it have already been done, and I posted an early prototype.
But I never got back to it.  The Ada folks expressed some interested,
and I think Fred did too, but so far nothing's come of it.

-- 
Daniel Jacobowitz
CodeSourcery


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