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: gdb-patches at sourceware dot org
- Date: Fri, 21 Jun 2013 14:41:28 -0600
- Subject: Re: RFC: fix PR backtrace/15558
- References: <87li6nghhz dot fsf at fleche dot redhat dot com> <51B11E66 dot 70102 at redhat dot com>
Pedro> Yeah, I was suggesting that "internal" / non-user-facing code
Pedro> should not be using get_prev_frame, but get_prev_frame_1 instead,
Pedro> bypassing all the checks. (Or rather wondering why that isn't
Pedro> so). Strongly more so in an unwinder's innards. get_prev_frame
Pedro> uses need to be investigated on a case-by-case manner manner to
Pedro> decide the best course of action, IMO.
I agree from a design standpoint that this is superior.
My main concern is that I am not confident that all the unwinders in the
tree actually stop sanely. If we believe that they do then it seems
straightforward to do the split as you suggest.
Normally I don't like to code to work around potential bugs elsewhere.
However in some parts of gdb, like this one, it is difficult to do
otherwise, due to the testing problem.
Anyway, this is why I split the function where I did.
Pedro> So conceptually, in this case, I think what makes most sense it
Pedro> to skip _all_ the checks in get_prev_frame* that might return
Pedro> NULL, as there should always be a prev frame for an inline frame.
Pedro> IOW, in this case, I believe we should be making
Pedro> inline_frame_this_id call get_prev_frame_1, or whatever it gets
Pedro> renamed to, or equivalent.
That sounds reasonable. I'll rework the patch next week.
Tom