Re: Helping out GDB

[dberlin at redhat dot com (Daniel Berlin+list.gcc)]

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

> > 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.
> 
> I don't follow. Given
> 
> struct X{
>   virtual void foo();
> };
> 
> void X::foo(){}
> 
> when compiled with -g, I get a line
> 
> .stabs "__vt_1X:G(0,32)=ar(0,1);0;3;(0,22)",32,0,3,0
> 
> Right here, you can see it's vtable thunks. Is this not debug info?

Yes, it is.
Is it the same for DWARF2 (I don't have a vtable thunks platform lying around, and don't remember what number to use with -fvtable-thunks).

> 
> > > 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)?
> 
> For the new ABI ones, yes, I can.

Works for me.
> 
> > I know quite a few people who want to break when the "blah"
> > exception is *thrown*.
> 
> I see. Even though there is more than one function that is used for
> this purpose, there actually is a limited number of them. So would it
> help if the gdb team is informed whenever something changes here? 

Yes, that would be great.
> We
> could certainly put a comment in the code saying "please send a
> message to <gdb@somewhere>" when you change the interface in this
> file.

That was the main worry, that it would break without us finding out until way too late.

> 
> > > For example, __cp_push_exception indeed has all the information you
> > > want.
> > 
> > Not in a form i can easily parse.
> 
> Why is that? I think the arguments to __cp_push_exception are
> well-specified.

I meant parse as in "extract info from", not understand what they mean.
Fer instance, how do i get the exception type being thrown, and where it was thrown from (I suppose i could always just look a few frames upwards to see where we called it from, or look at __eh_pc), from cp_push_exception?
IE is the type parameter a pointer to RTTI info, etc?

> 
> > And then, i got complaints from people who have platforms still
> > using other forms of exceptions.
> 
> What exactly where those complaints?

That cp_push_exception/cp_pop_exception didn't exist, IIRC.
I could be wrong, of course, my memory ain't so good anymore.
I'm willing to tell these people to upgrade to a newer gcc if the exception interface is going to stay standard for a while. 

> 
> > 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.
> 
> If you want to break when the "blah" exception is *thrown*, you don't
> need to know anything about dwarf2.

Yeah, just realized that.
>  However, given that DWARF2 is a
> format of debugging information, it may be a good idea if the debugger
> supported it, anyway :-)
It already does.
However, we don't parse/use the frame unwinding information.
But it appears we don't need to.

> 
> Regards,
> Martin