This is the mail archive of the archer@sourceware.org mailing list for the Archer 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: Tasks (exception round-up)


Tom> * Exceptions.  Look at the existing longjmp stuff, come up with
Tom> an estimate for the new work.

Phil> Can you elaborate a little more on this. I was hoping it would become
Phil> clearer as I investigated.

gdb has some existing code to handle setjmp/longjmp "properly".
Unfortunately I think this code doesn't work on Linux, due to a
security feature of glibc; but if you can scare up a Solaris box or
something you might be able to play around with it.

Anyway, this was just a suggestion -- don't get too hung up on it.  It
may well be that exception handling is sufficiently different that we
can't compare the two.

Phil> The only issue I have encountered is attempting to step in the catch
Phil> exception handler code causes GDB to lose control of the inferior in
Phil> certain circumstances:

Take a look at the appended program, which is a modification to the
one you posted.

In gdb, put a breakpoint on main.  Then, step into func1.  In func1,
type "next".

What I expect to happen is that gdb regains control in the "catch".

What actually happens is that the inferior continues, prints a
message, and exits.

This problem is not a debuginfo thing -- it is a missing feature in
gdb.

Phil> catch throw foo and catch catch foo with named exceptions would
Phil> totally rock. I can attempt to estimate the work there, if needed. I
Phil> would like them, would it be a generally useful thing for others?

Yeah, I think so.

Phil> Another nit is the catch catch and catch throw breakpoint is in the
Phil> libstdc++ code, not in the inferior throw foo or catch foo code. This
Phil> is personally not useful; I've no interest in the libstdc++ code and
Phil> beyond a libstdc++ developer I'm not sure someone else would. Daniel
Phil> noted that this had been hacked on a bit, but breaks Eclipse (and I
Phil> guess by extension) other clients.

Yeah.  So, one thing here is to figure out what it would look like to
have this work, and then of course, estimate the effort here :).

Phil> - You cannot install an exception handler, or raise an exception in an
Phil> interactive session.

How would it look to install an exception handler from gdb?
This is an intriguing idea, I've never heard it before :)

For throw I guess we could write a 'throw' command.

Tom

#include <iostream>
#include <exception>


using namespace std;

class simple : public exception
{
  virtual const char* what() const throw()
  {
    return "simple exception occurred";
  }
} simple;

int func2() {
  throw simple;
}

int func1 () {
  return func2();
}

int main () {
  try {
    func1();
  }
  catch (exception &e) {
    cout << "Exception: " << e.what() << endl;
  }
  return 0;
}


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