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

[Yao Qi <qiyaoltc at gmail dot 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 (齐尧)