DynamoRIO / dynamorio

Dynamic Instrumentation Tool Platform
Other
2.64k stars 560 forks source link

add buffer filling convenience API #513

Open derekbruening opened 9 years ago

derekbruening commented 9 years ago

From bruen...@google.com on July 15, 2011 11:07:19

we should add a buffer filling convenience API. probably based on the PiPA design. should have the memtrace sample use it.

Original issue: http://code.google.com/p/dynamorio/issues/detail?id=513

derekbruening commented 9 years ago

From bruen...@google.com on September 28, 2011 08:15:20

Labels: GoodContrib

derekbruening commented 9 years ago

From byron.c....@gmail.com on March 26, 2014 19:04:12

[Edit] A sketch for the API is attached. If it looks ok, I'll code it up and submit for review.

Attachment: rotating_buffer_api.h

derekbruening commented 9 years ago

From zhao...@google.com on March 31, 2014 11:19:26

I think it is better to use a few concrete examples, e.g., bbbuf and memtrace. For bbbuf, it is simple as the value is determined at instrumentation time: we want

  1. init to claim
    • buffer size
    • per-thread or process: per-thread
    • what to do when buffer is full: simply recycle from top.
    • how to iterate the buffer at anytime in reverse order
  2. filling the buffer
    • calling the API with bb-tag is passed in

For memtrace, it is more complicated

  1. init to claim
    • buffer size
    • perthread
    • buffer-full function: call a clean call to dump
    • iteration: not necessary
  2. filling the buffer
    • the address is most likely in an register, or could be statically known, so we want to support both a reg or a "byte *entry" value.

More advanced, can we support multiple insertions with one buffer pointer adjust for better performance.

derekbruening commented 9 years ago

From byron.c....@gmail.com on March 31, 2014 16:15:09

Should there only be one buffer for now? I notice in PiPA there can be multiple buffers.

I completely forgot about filling the buffer from the code cache :-P

  1. For a "byte *entry", is it assumed to be null terminated? Or fixed size?
  2. Should the client optionally be able to specify length per entry, maybe in a register?
  3. Will there be an API function for inserting into the buffer from C code?

If the entries are not fixed size, is a terminator used for iteration? Or a length meta-field? I was thinking the client would just code their own iterator in C; should that still be possible?

derekbruening commented 8 years ago

We have some recent design discussion here: https://docs.google.com/document/d/147PRuEp_T67lwr2fbWx5XOlj5r_Gli4-4vyKfoUBMUw/edit?usp=sharing

derekbruening commented 8 years ago

If the buffer filling API includes the use of faults for handling full buffers, it could help with #1698 by eliminating explicit instrumentation and esp clean calls in tracing tools in problematic places like between ldrex..strex pairs. It is possible that the buffer could keep filling up at exactly the same point but it is unlikely, or at least it seems less likely than the problematic scenarios of the current instrumentation schemes.