This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: GDB 8.0 release/branching 2017-03-20 update
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: "Wiederhake\, Tim" <tim dot wiederhake at intel dot com>
- Cc: Joel Brobecker <brobecker at adacore dot com>, "Metzger\, Markus T" <markus dot t dot metzger at intel dot com>, "gdb-patches\@sourceware.org" <gdb-patches at sourceware dot org>, "xdje42\@gmail.com" <xdje42 at gmail dot com>
- Date: Fri, 07 Apr 2017 16:19:06 +0100
- Subject: Re: GDB 8.0 release/branching 2017-03-20 update
- Authentication-results: sourceware.org; auth=none
- References: <86a885o0z2.fsf@gmail.com> <A78C989F6D9628469189715575E55B2340076209@IRSMSX104.ger.corp.intel.com> <861stgo072.fsf@gmail.com> <A78C989F6D9628469189715575E55B23400775CC@IRSMSX104.ger.corp.intel.com> <86lgrn3uos.fsf@gmail.com> <A78C989F6D9628469189715575E55B2340077BD3@IRSMSX104.ger.corp.intel.com> <86h92a4w86.fsf@gmail.com> <A78C989F6D9628469189715575E55B2340077D34@IRSMSX104.ger.corp.intel.com> <86h929wnxi.fsf@gmail.com> <A78C989F6D9628469189715575E55B234007804A@IRSMSX104.ger.corp.intel.com> <20170331160246.xjlqgrrkayprdmba@adacore.com> <9676A094AF46E14E8265E7A3F4CCE9AF3C134157@IRSMSX106.ger.corp.intel.com> <86fuhkk58b.fsf@gmail.com> <9676A094AF46E14E8265E7A3F4CCE9AF3C1342D2@IRSMSX106.ger.corp.intel.com>
"Wiederhake, Tim" <tim.wiederhake@intel.com> writes:
> Imagine you have some code like this:
>
> void
> a ()
> {
> /* some code */
> }
>
> void
> b ()
> {
> /* some code */
> a ();
> /* some code */
> }
>
> Then the trace for a call to function "b" would generate three function call
> segments: One for the code in "b" before the call to "a", one for the code in
> "a" and one for the code in "b" after the call to "a" returned.
>
> The "next" attribute in the first function segment points to the third function
> segment and likewise the "prev" attribute in the third function segment points
> to the first function segment. For the second function segment the "up"
> attribute points to the first function segment.
>
> "Segment" is used instead of "Call" throughout the btrace code to avoid the
> impression that one function segment contains the whole recorded data for a
> function call whereas it only contains a part of it. I believe we should
> continue this terminology in Python.
>
OK, "Segment" is fine with me.
>> > The user needs to distinguish between instructions and gaps somehow
>> > anyway, and
>> > this solution would let them do so quite nicely. Example code:
>> >
>> > r = gdb.current_recording()
>> > for insn in r.instruction_history:
>> > try:
>> > print insn.pc, insn.sal
>> > except:
>> > # It's a gap!
>> > print insn.error_message
>> >
>> I don't like using exception for control flow.
>
> The above code with the "error" attribute still in place would look like this:
>
> r = gdb.current_recording()
> for insn in r.instruction_history:
> if not insn.error:
> print insn.pc, insn.sal
> else:
> print insn.error_message
>
> The user has to take care about the rare possibility of a gap occurring in the
> trace. In the latter case, they have to explicitly check that the instruction
> they look at is not a gap, which is easy to forget and will lead to strange
> results as the "pc", "sal", "data", "size" and so on attributes of a gap do not
> contain meaningful data.
>
> In the former example, the exception is raised by accessing "insn.pc", an
> attribute that does not exist for a gap. I expect the usual code for the
> "except" path to just contain a "pass" or "continue" statement. I just printed
> the error_message in the example to showcase how this situation would be handled
> if a user desired so.
>
> If you wanted to write this example without handling exceptions, you could do
> so as well:
>
> r = gdb.current_recording()
> for insn in r.instruction_history:
> print getattr(insn, "pc", "has no address"), getattr(insn, "sal", "has no sal")
>
> And even if the user simply wrote:
>
> r = gdb.current_recording()
> for insn in r.instruction_history:
> print insn.pc, insn.sal
>
> there are two cases: The trace contains no gaps (common), or the trace contains
> gaps (uncommon). If the trace did not contain any gaps, the code works as
> expected. If the trace contained gaps, Python will raise an exception pointing
> in the right direction of the problem.
>
> If instead we continued to offer the "error" attribute and the user forgot to
> check, the code would silently fail and produce wrong results. I believe the
> option where we fail loud and clear is favorable over the silently wrong result.
>
>> If I understand "gap"
>> correctly, it is caused something interrupt the tracing.
>
> There might be other causes as well, such as overflows, decoding errors, etc.
> Again, ideally the trace contains no gaps at all, but rarely it may contain one
> or more gaps interleaved with the regular instructions.
>
Is it possible that gap is not caused by error? As I said in previous
mail, user may want to trace a block of instructions, instructions out
of this range are regarded as gap. My point is that we need to define a
general reason in gap instead of error.
>> I'd like to
>> change the interface like this,
>>
>> gdb.InstructionHistory
>> a list of gdb.RecordInstruction
>> gdb.RecordGap (or gdb.RecordStopReason)
>>
>> It saves a list of instructions and why the record is stopped or
>> interrupted. It can be different reasons, like hardware limitation,
>> or user preference (user only wants to record/trace instructions
>> executed in current function foo, so any function calls in foo will
>> cause a gap in the history. In this way, gdb.RecordGap don't have to be
>> an error).
>>
>> gdb.Record.instruction_history returns a list of gdb.InstructionHistory.
>
> Just to make sure: You propose that gdb.Record.instruction_history returns a
> list of partial lists, and each partial list contains the reason why that
> particular partial list was interrupted / stopped, correct?
Yes.
>
> Generating this list of lists would be quite expensive as we have to go over the
> whole list of instructions (that at least for btrace internally /is/ a list of
> instructions interleaved with gap objects), count the gaps and save their
> position to know the length of this list of lists and the start and end of the
> individual sub lists. With the explanation above how to do this without having
> to care about exceptions, would you agree on keeping the list one-dimensional,
> with instructions and rarely gaps interleaved as-is?
OK, that is fine to me.
--
Yao (齐尧)