RE: record-btrace

["Metzger, Markus T" <markus dot t dot metzger at intel dot com>]

> -----Original Message-----
> From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com]
> Sent: Tuesday, January 29, 2013 10:53 AM

Hi Jan,

Thanks for the quick reply!


> On Mon, 28 Jan 2013 17:13:59 +0100, Metzger, Markus T wrote:
> > 1. add a new command "record-btrace" that pushes a new
> 
> "record btrace", there are already subcommands of "record".
> 
> It would be unconvenient to have some subcommands as "record-ABC" and some as
> "record DEF" wrt tab-completion.

OK. So the targets will be called "record-full" and "record-btrace" and can be used directly with the "target" command; the "record" command will use sub-commands. We thus have:

"target record-full"
"target record-btrace"
"target record" aliases "target record-full"
"record full"
"record btrace"
" record" aliases "record full"

If we now want to add LBR-based branch tracing, we could either change record-btrace to record-btrace-bts and add record-btrace-lbr or make "bts" and "lbr" configuration options of record-btrace. The former leads to very long names and commands; the latter requires "set/show record" commands to be usable even if no or the wrong record target is currently active.


> > The existing brace target-ops and also the btrace RSP packets will need to
> > remain since I still need to configure branch tracing on the target. Without
> > them (i.e. the functionality hard-coded in record_btrace_target_ops),
> > I don't see how I could handle the remote case. Record_btrace_open will call
> > target_btrace_enable to do the actual work. It will fail if one of the
> > btrace enable calls fails.
> 
> OK; therefore two btrace struct target_ops for linux-nat.c vs. remote.c and one
> btrace struct target_ops for record btrace (vs. full).

If you're OK to keep the btrace target_ops methods, we shouldn't need separate target_ops structs for native and remote. The btrace methods will be supplied by the native and remote targets. The record-btrace target will be on top  and use the btrace methods from the target beneath.


> > I may need to allow reading memory for read-only dynamic sections so that at
> > least "disas" works. Does gdb maintain a dynamic section map? Could gdb be
> > taught to read this memory from a file, instead?
> 
> I would not be too strict with accessing the inferior memory.  I understand
> that the memory content may be different when GDB is in the btrace history but
> most of the memory including read/write variables a user may want to read will
> be the same.
>
> It could rather just print a CLI (the default command-line interface) warning
> if one accesses a read/write memory during command execution.
> 
> Forbidding any memory access may be correct but it may be pain for the users.

I would find this very confusing. Stack and heap might not be available any more - or might contain different objects.

I can do the CLI warning as first step. Will this warning also be available via MI? Do you know whether gdb is reading memory for some internal logic?


> > When they reach the end of the trace, they turn into normal stepping
> > commands, i.e. I will forward to_resume and to_wait to the target beneath.
> > This should implicitly continue other threads depending on the execution
> > mode. When the target stops next time, the tracing positions for all stopped
> > threads will be reset - I won't be able to find the old position in the new
> > version of the trace. This behavior might be somewhat surprising if you
> > switched threads while traversing the history.
> 
> I would rather print an error in such case - that one should switch to the
> thread with position in history and roll it back to the current position
> before the whole process can be resumed by the target beneath.

That can easily become quite annoying if you have several threads. We could query the user if he wants to continue even though some threads are somewhere in the history. How would this work for MI?

Is scheduler-locking implemented by the step commands or by the target's to_resume and to_wait functions?

I have only considered a single inferior, so far.

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