record-btrace

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

Hi Jan,

I was interrupted by some other task. Now I'm switching back to btrace and to your request for merging it with record. Let me try to recap what you're asking for and sketch a preliminary plan for you to comment on.

1. add a new command "record-btrace" that pushes a new record_btrace_target_ops onto the target stack. By default, this will enable branch tracing for all existing and all new threads. Arguments may later be added to only enable branch tracing selectively for some threads.

This record_btrace_target_ops will be fairly empty in the first step. We don't support reverse execution, yet. The only effect should really be to prevent record and btrace from co-existing.

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.

The target is global. The data (i.e. configuration, history), however, will still be per-thread. I don't know how target record handles this. I was thinking of keeping the btrace internal structure.

If we're going to extend this in the future, say, by adding an LBR-based branch trace, this would be another record_btrace_lbr_target_ops that may share some of the functions with the BTS-based record-btrace target.

You mentioned that we should not pop that target when the process terminates to implement auto enabling for new processes. I'm not quite clear how that will work. I always thought the target stack is newly setup for each process. I wonder how we can leave the topmost entry always on?


2. implement the standard "record" commands for this new record-btrace target, i.e. "info record", "set/show record", "record goto", "record save", "record restore", "record stop", "record delete".

The "set/show record" sub-commands won't make much sense for record-btrace. On the other hand, we would need some other sub-commands to configure branch tracing. Would I dynamically add and remove those (sub-)commands depending on which record target is currently active? I have not seen functions to remove commands. Or would I need to put sub-command handling into a single "set record" and "show record" command (i.e. do not use sub-commands)?

The "info record" command makes sense for all record variants, but it will show different information for each record target. Would I add a new target-ops function for it? Or would I add a new struct record_ops to collect those functions?

The "record save/restore" commands won't be available. Needs more target-ops or record-ops functions.

The "record goto" and "record delete" commands will need to work on btrace data structures, instead. Needs more target-ops or record-ops functions.

I would essentially move those commands into a new file and implement some record abstraction for them to work on.


3. add a new "record disas" sub-command to print the disassembly of the last instructions and iterate through the instruction history similar to the list command. This will be disabled for target record and implemented for target record-btrace.

I would add another target_ops or record_ops function to do the actual work that is called from the "record disas" command.

In a later step, this could be implemented for target record, as well.


4. add a new "record list" sub-command similar to "record disas" but listing the source lines that have been executed.


5. extend "record stop" to take parameters that allow selective disabling of branch tracing. Not sure if and how this will work with the existing target record.


6. Implement reverse execution for record_btrace_target_ops:

To_resume/to_wait: iterate through instruction history
To_insert_breakpoint: maintain breakpoint list - don't forward to target
To_fetch_registers: only support the instruction pointer register
To_store_registers: not allowed
To_xfer_partial: not allowed
To_~_watchpoint: not allowed

When I don't allow reading memory in target record, nothing works, anymore, i.e. almost all gdb commands fail.
When I don't allow fetching registers in target record, there seems to be no impact - I guess the regcache is up-to-date so we don't really need to ask the target.
When I do a single reverse stepping command, however, it fails and gdb believes that the target is executing - nothing works, anymore.

The first experiment is not very encouraging. Do you think this can be done, at all?

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 may also need to replace the unwinder even though I'm not adding unwind support, yet - just to prevent it from failing. Are unwinders global or can a target add/remove unwinders? If unwinders can't be added/removed dynamically, I would add an unwinder to target_ops that will, if present, precede all other unwinders. Would that be OK?

I would like to simulate the above two (i.e. allow access to read-only memory and add a do-nothing unwinder) to see what issues we might be running into with a target record-btrace. Would you help me with that?

Reverse- and subsequent forward- stepping command should target the current thread only as long as the thread is inside the recorded execution history. I hope that's what I get when I overwrite to_resume and to_wait and only consider the current thread.

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.


Thanks,
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