Re: GDB 8.0 release/branching 2017-03-20 update

Yao Qi
2017-04-07T15:19:15Z

"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 (齐尧)