This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [rfc 6/8] record disas: omit function names by default


> -----Original Message-----
> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Jan Kratochvil
> Sent: Monday, February 18, 2013 2:03 PM

> On Mon, 18 Feb 2013 10:42:44 +0100, Metzger, Markus T wrote:
> > I don't insist on the names I gave those commands, but I'd rather we had a single
> > word for each command.
> 
> Due to <tab> completion and GDB abbreviations I do not think a single word is
> required, as discussed occasionally in other cases on gdb-patches.
>
> > Consider the existing "list" and "backtrace" commands. With the same arguments,
> > they should be renamed into "list-source-lines" and "list-call-frames";-)
> 
> I see the problem in that these names already have some established meaning
> now while you overload these names for a different functionality in btrace.

That's the point I was trying to make with the table in my previous email. I'd rather say
I took those commands and applied them to a recorded execution history.


> > Jan described it nicely above: "it's a 'backtrace' into history, not into upper frames".
> > The term 'backtrace' suggests it's backwards and about functions. Being a "record"
> > sub-command suggests it's working on the execution log.
> 
> I got used to it now but for new users it is not obvious enough.

How long did it take you?


> "backtrace" is very fundamental commands of GDB with well known semantics.
> 
> Is that "record trace-functions" OK for you?

"record trace-functions" sounds like it would enable tracing functions.

If it has to be some two-word combination, I'd rather go with "record list-", i.e.
"record list-functions", "record list-lines", and, for the sake of consistency,
"record list-instructions".

Or are you OK with "record disassemble" and "record list" and just objecting
to "record backtrace"?


> > The "btrace list" command that Jan mentioned works on blocks, i.e. sequentially
> > executed code between two branches. This would be between "record list" and
> > "record backtrace". I have not added a similar command to "record".
> 
> Is this the intended final state or do you still plan updating
> archer-mmetzger-btrace?  I would find the "btrace ..." commands more suitable
> to be placed under "record btrace ...", so that one has all the available
> "record btrace ..." commands at one place with "record btrace <tab><tab>".
> 
> There can be "btrace ..." ones as aliases to them (although I do not think it
> is needed, user can create an alias using the 'alias' command easily if
> needed).

I intend to remove the "btrace" command and all its sub-commands. I just kept them
so people can compare them with the new "record" commands.

Regarding "brace list" I do not plan to add a corresponding "record" command.

Regards,
Markus.
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]