GDB 8.0 release/branching 2017-03-20 update

[Yao Qi]

"Wiederhake, Tim" <tim.wiederhake@intel.com> writes:

Hi Tim,
I was off yesterday.  Thanks for the summary.

> The Python interface shall look like this (from Python's perspective):
>
> gdb:
> 	Record		start_recording([str method], [str format])
> 	Record		current_recording()
> 	None		stop_recording()
>
> 	Unchanged.
>
> gdb.Record:
> 	str		method
> 	str		format
> 	RecordInstruction	begin
> 	RecordInstruction	end
> 	RecordInstruction	replay_position
> 	RecordInstruction[]	instruction_history
> 	RecordFunctionSegment[]	function_call_history
> 	None		goto(RecordInstruction insn)
>
> 	gdb.Record loses the "ptid" attribute.  "instruction_history" and 
> 	"function_call_history" actually returns a "list" or "list-like object"
> 	as there is no way to enforce the type of elements in this list on a
> 	language level in Python.  Practically, these list will always contain
> 	"RecordInstruction" / "RecordFunctionSegment" objects since we control
> 	their creation.  "*_history" may return "None" if the current recording
> 	method cannot provide such a list.
>

> gdb.Instruction:
> 	int		pc
> 	buffer		data
> 	str		decode
> 	int		size
> 	
> 	gdb.Instruction is meant to be an abstract base class.  The user will
> 	never receive a raw gdb.Instruction object and accessing any attribute
> 	in this class will throw a "NotImplementedError" (from what I
> 	understand, that's the preferred way to handle this kind of situation
> 	in Python).

From the implementation point of view, it can be an abstract base class,
but we don't have to mention it in Python/Document.  Likewise, we don't
apply the restriction that "user will never receive a raw
gdb.Instruction object" on the Python interface.

>
> gdb.RecordInstruction (gdb.Instruction):
> 	int		pc	<inherited from gdb.Instruction>
> 	buffer		data	<inherited from gdb.Instruction>
> 	str		decode	<inherited from gdb.Instruction>
> 	int		size	<inherited from gdb.Instruction>
> 	int		error
> 	gdb.Symtab_and_line	sal
> 	bool		is_speculative
> 	
> 	gdb.RecordInstruction is a sub class of gdb.Instruction. It loses
> 	the "number" attribute.  "error" will be "None" if there is no error.
>

> gdb.<Whatever>Instruction (gdb.Instruction):
> 	int		pc	<inherited from gdb.Instruction>
> 	buffer		data	<inherited from gdb.Instruction>
> 	str		decode	<inherited from gdb.Instruction>
> 	int		size	<inherited from gdb.Instruction>
> 	...
> 	
> 	Created by other Python interfaces, e.g. a function that dissasembles
> 	target memory.

Right, to be clear, we focus on record/btrace instruction.

>
> gdb.RecordFunctionSegment:
> 	gdb.Symbol	symbol
> 	int		level
> 	gdb.RecordInstruction[]	instructions
> 	gdb.RecordFunctionSegment	up
> 	gdb.RecordFunctionSegment	prev
> 	gdb.RecordFunctionSegment	next
> 	
> 	Renamed from "gdb.BtraceFunctionCall" to better fit the general scheme.

"Segment" is less clear than "Call".  Does this object represent
something other than a function call?

> 	Loses the "number" attribute.  As above, "instructions" actually returns
> 	a list / list-like object.  "prev_sibling" and "next_sibling" are
> 	renamed to "prev" and "next" for simplicity (discussed with Markus
> 	off-list).

It is a good renaming to me.

> 	
> Correct so far?
>

Yes, I think so :)

> Initially I supported the idea of losing the "number" attributes in
> "gdb.RecordInstruction" and "gdb.RecordFunctionSegment", but I see a
> problem with that now:  If an instruction is executed multiple times (e.g. in a
> loop), all user visible attributes for these gdb.RecordInstruction objects are
> the same, nevertheless a comparison with "==" does not yield "True" because they
> represent, well, two different instances of execution of that instruction.
> Keeping the "number" attribute in would show the user, why those objects are not
> equal.  Therefore I propose to retain the "number" attribute in
> "gdb.RecordInstruction" and for symmetry in "gdb.RecordFunctionSegment" as well.
>

As far as I can see, it is not a problem to me.  The multiple instances
of the same instruction are different, because the same instruction
executed multiple times.  IOW, gdb.RecordInstruction from different
slots of .instruction_history are different.

> Markus and I further discussed how we handle gaps or other errors in the trace
> from the Python point of view.  We came to the conclusion that it would be
> beneficial for the user if we replaced the definition of "gdb.RecordInstruction"
> above with the following two:
>
> gdb.RecordInstruction (gdb.Instruction):
> 	int		pc	<inherited from gdb.Instruction>
> 	buffer		data	<inherited from gdb.Instruction>
> 	str		decode	<inherited from gdb.Instruction>
> 	int		size	<inherited from gdb.Instruction>
> 	int		number
> 	gdb.Symtab_and_line	sal
> 	bool		is_speculative
> 	
> gdb.RecordGap:
> 	int		number
> 	str		error_message
> 	int		error_code
>
> 	Does NOT inherit from gdb.Instruction.
>
> gdb.Record.instruction_history would then not "return a list of
> RecordInstructions" but instead "return a list of RecordInstructions and
> (potentially) RecordGaps".

Yeah, I can see the motivation of this change, because it is strange to
have a field "error" in gdb.RecordInstruction to indicate this.

>
> 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.  If I understand "gap"
correctly, it is caused something interrupt the tracing.  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.

-- 
Yao (齐尧)