This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB 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: RFC: fix PR backtrace/15558


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


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