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

Yao Qi
2017-04-07T08:10:53Z

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