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: "Wiederhake, Tim" <tim dot wiederhake at intel dot com>
- To: Joel Brobecker <brobecker at adacore dot com>, "Metzger, Markus T" <markus dot t dot metzger at intel dot com>
- Cc: Yao Qi <qiyaoltc at gmail dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, "xdje42 at gmail dot com" <xdje42 at gmail dot com>
- Date: Thu, 6 Apr 2017 14:40:44 +0000
- Subject: RE: GDB 8.0 release/branching 2017-03-20 update
- Authentication-results: sourceware.org; auth=none
- Dlp-product: dlpe-windows
- Dlp-reaction: no-action
- Dlp-version: 10.0.102.7
- 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>
Hi all,
> Tim, are you OK with the result of this discussion, as well?
I'm back and have read the mails you all wrote about this topic. Let me
summarize to make sure I understand everything correctly.
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).
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.
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.
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).
Correct so far?
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.
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".
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
Please let me know if you agree with this so I can get to work as soon as
possible.
Regards,
Tim
> -----Original Message-----
> From: Joel Brobecker [mailto:brobecker@adacore.com]
> Sent: Friday, March 31, 2017 6:03 PM
> To: Metzger, Markus T <markus.t.metzger@intel.com>
> Cc: Yao Qi <qiyaoltc@gmail.com>; Wiederhake, Tim
> <tim.wiederhake@intel.com>; gdb-patches@sourceware.org;
> xdje42@gmail.com
> Subject: Re: GDB 8.0 release/branching 2017-03-20 update
>
> > Tim, are you OK with the result of this discussion, as well?
> >
> > Joel, do we have a week or so for Tim to send a patch?
>
> We do (I am going to be away all of next week). After that, let's cut the
> branch no matter what, and backport if necessary.
> I'd like to start soon, so as to give time for stabilization if needed.
>
> --
> Joel
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928