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

Metzger, Markus T
2013-02-18T09:43:19Z

> -----Original Message-----
> From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com]
> Sent: Friday, February 15, 2013 8:10 PM

> On Fri, 15 Feb 2013 20:05:38 +0100, Eli Zaretskii wrote:
> > > It is a "backtrace" into history, not into upper frames.
> > > (gdb) record backtrace
> > > _IO_vsnprintf
> > > _IO_vfprintf_internal
> > > strchrnul
> > > _IO_vfprintf_internal
> > > __GI__IO_default_xsputn
> > > You can see _IO_vfprintf_internal called strchrnul which then returned back to
> > > _IO_vfprintf_internal. This is not a real "backtrace".
> > >
> > > I was already considering renaming the command as the term is a bit overloaded
> > > in the debugger context.
> > >
> > > Maybe "record list-functions"?
> >
> > How about "record trace-functions"?
>
> "trace-functions" is fine with me; we'll see what Markus says.

I don't insist on the names I gave those commands, but I'd rather we had a single
word for each command.

Consider the existing "list" and "backtrace" commands. With the same arguments,
they should be renamed into "list-source-lines" and "list-call-frames";-)
The problem with such command names is that they are awful to type and
abbreviations will be quite cryptic, e.g. "lsl" or "lcf".

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.

The idea of those three new commands is to provide a quick overview of the
execution history at different levels of granularity. Each of those commands
allows iteration similar to the "list" command. The different levels of granularity
are:
record disassemble ......... instructions
record list ....................... source lines
record backtrace ............. functions

I picked those terms for the record sub-commands that are associated with the
respective level of granularity, already.

It takes some practice to read the output of the above commands. Once you got
the hang of it, though, they give a very nice and compact overview of the recorded
control flow. The "record list" command will be the most difficult to make sense of
in the beginning.

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".

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