This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


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

Re: Helping out GDB


"Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de> writes:

> > As the C++ maintainer for GDB, I run into a lot of fun problems
> > where g++ isn't providing info we need.
> 
> While I strongly sympathize with the need to support gdb as good as
> possible, I can't see some of the problems you have.
> 
> > First and formost, for the old ABI, i have no way to detect what
> > kind of vtable thunks the platform is using, or lack thereof.
> 
> Why is that? If the symbols start with __vt_, it's vtable thunks; if
> they start with __vt., it's old-style vtables. Is that difficult to
> tell apart?

Yes.
Because in the debug info, they are always specified a different way (which is a *good thing*).
So now i have to go hunting through the minimal symbols, just to see if something was a vtable thunk or not.
This is a very expensive (time wise) idea in GDB.


> 
> > I have no way to tell whether something was compiled with the new or
> > old abi.
> 
> Sure you do. Mangled symbols of the new ABI all start with _Z (except
> for the extern "C" ones, of course); there won't be any __vt symbols.
> If that is not enough identification, I could also give you a list of
> functions that will be there.

And you can guarantee me this won't change for a release (IE 3.x)?
I don't want to run into the same problem people did when the solution was gcc2_compiled.

> 
> > That's just a bad hack because gcc isn't telling us what we need to
> > know.
> 
> If the approaches above don't work, please elaborate what problems
> they cause.

> 
> > It would be nice if GCC, like a few other compilers, provided a
> > callback so that I could say "when you get an exception in the
> > program, call this routine", and it would call the callback with a
> > few key parameters that i could use to tell what was thrown/caught
> > and where.
> 
> I'm not sure I understand this request. First, are you aware of
> __unwinding_cleanup? One problem with debugging exceptions is that it
> is ok for an exception to occur as long as it is going to be caught,
> so in a debugger, I'd like to break only if an exception is thrown
> that won't be caught; this is what __unwinding_cleanup is for.

I know quite a few people who want to break when the "blah" exception is *thrown*.
__unwinding_cleanup doesn't let me do that.

> 
> I can't see what the callback routine would achieve. For C++ alone,
> there are different ways to initiate stack unwinding, specifically
> throw <value>; and throw;. They require different entries into the
> run-time system, and likely would also require different callbacks.
No, they wouldn't.
HP, for instance, notifies GDB of all throws and catches with one callback, and provides sufficient information in the arguments of the callback to do all of this.

> For example, __cp_push_exception indeed has all the information you
> want.

Not in a form i can easily parse.
I tried before.
And then, i got complaints from people who have platforms still using other forms of exceptions.

I'm perfectly willing to put the time and effort into writing something than can parse the dwarf2 info being used for exception handling, if I know that this is going to be the way exceptions are done from now on.

> 
> > A callback would also remove the problem of their being so many
> > different implementations of exception handling, since GDB would no
> > longer have to care about how it was implemented.
> 
> Can you propose a specific ABI that you want to use. I have a hard
> time guessing what the requirements should be.
> 
Sure, i'd be happy to.
Give me a few days.

> Regards,
> Martin


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