This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: fix PR backtrace/15558
- From: Tom Tromey <tromey at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Andrew Pinski <pinskia at gmail dot com>, "gdb-patches\ at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Mon, 14 Apr 2014 12:52:08 -0600
- Subject: Re: RFC: fix PR backtrace/15558
- Authentication-results: sourceware.org; auth=none
- References: <87li6nghhz dot fsf at fleche dot redhat dot com> <51B11E66 dot 70102 at redhat dot com> <87mwqjw613 dot fsf at fleche dot redhat dot com> <CA+=Sn1ko3pK8+2VPgGBeiQ3j1uVWf+sxNXHRrX==ed4L-wCp+w at mail dot gmail dot com> <87ha5vrdki dot fsf at fleche dot redhat dot com> <534C2C19 dot 1010503 at redhat dot com>
Tom> I never got back to fixing it according to Pedro's review.
Tom> As I recall it isn't entirely trivial because for a good fix one would
Tom> need to expose some new Python methods for use by the frame filter code.
Pedro> Hmm. Not sure what you're thinking of.
There's a good chance I'm confusing it with some other approach I'd
considered.
Pedro> We discussed auditing all
Pedro> get_prev_frame uses and see if they are better replaced by
Pedro> get_prev_frame_1, but I don't think that should hold back
Pedro> fixing the inline frame unwinder.
Ok.
I think what I was thinking is that if one starts this change, then the
question arises: which should the Python unwinder call? Calling the
user-facing one is plainly incorrect. But, calling the internal one is
also incorrect, as some termination conditions may be skipped.
Perhaps this only applies if we move all the checks into get_prev_frame_1.
I don't recall whether that was part of the plan or not.
Tom