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


> 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?

> > 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.

> 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? 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.

> > 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.

> And then, i got complaints from people who have platforms still
> using other forms of exceptions.

What exactly where those complaints?

> 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. However, given that DWARF2 is a
format of debugging information, it may be a good idea if the debugger
supported it, anyway :-)

Regards,
Martin

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