Handling of OUT function arguments for "apitrace trim"

[José Fonseca]

Carl,

Indeed the current parser pairs enter/leave events into a single call
irreversibly.

For most use cases that level of detail is adequate, and I don't think
no current no apitrace code cares about that.

It's possible that in the future we may need to be more accurate to
handle multithreaded or re-entrant APIs. The solution I envision long
term for that is to have entry/leave events be first class objects,
contained on every trace::Call.  I doubt this will be a problem, but
given the plan is to support binary traces till the end of times, if
you wanna guarantee "apitrace trim" 's output to be future proof then
it might be better to preserve this somehow, by putting a flag in the
arguments, or in the call signature.

Jose



On Wed, Nov 16, 2011 at 5:36 PM, Carl Worth <cworth at cworth.org> wrote:
> José,
>
> As I coded up some preliminary support for "apitrace trim" I tried to
> verify that I could read a trace in and then write an identical trace
> back out again.
>
> I found that the traces I generated were slightly different in byte
> content, but identical according to "apitrace dump".
>
> My code to write out a function looks like this:
>
>    unsigned __call = writer.beginEnter(call->sig);
>    for (unsigned i = 0; i < call->args.size(); ++i) {
>        writer.beginArg(i);
>        _visit(call->args[i]);
>        writer.endArg();
>    }
>    writer.endEnter();
>    writer.beginLeave(__call);
>    if (call->ret) {
>        writer.beginReturn();
>        _visit(call->ret);
>        writer.endReturn();
>    }
>    writer.endLeave();
>
> This causes a result that's different from the original trace because
> the original trace puts some of the argument values inside the "Leave"
> block rather than inside the "Enter" block, (for those arguments that
> are marked as OUT arguments in the specs).
>
> As far as I can see, the current code doesn't hold on to the information
> for which arguments are OUT arguments, so I wouldn't be able to generate
> an identical trace without augmenting something there.
>
> But then again, the current parser is also throwing away the information
> of which arguments are OUT arguments. So it occurs to me that no code
> using the current parser can even care whether the arguments are in the
> Leave or Enter blocks, (as long as they have the correct value).
>
> So I'm looking for your advice. Shall I go ahead with code like the
> above for the trim case? Or shall we extend the parser to identify which
> arguments are OUT arguments so that I can put those into the Leave
> block?
>
> -Carl
>
> --
> carl.d.worth at intel.com
>
> _______________________________________________
> apitrace mailing list
> apitrace at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/apitrace
>
>