The x64dbg trace format problem

[mrexodia]

Hello, it looks like a great tool you have here! Just wanted to let you know I’m available if you need help changing the x64dbg trace format. We have a mechanism to update the format without breaking things (in theory), so change is welcome!

[teemu-l]

Hello. Thanks, actually wanted to hear your opinion about the tool. :)
I will get back to you about the format problem when I have time. Yeah I think it should be an easy fix. Many unused bits in that memory access flag.

[torusrxxx]

Hello, I'm the author of x64dbg trace file specification. When the "memory access flag" was designed, it was expected that a disassembler is always available to a file reader, so the reader could determine whether a memory access was read or write access based on opcode. Therefore the tracer did a simple way which also makes the file smaller by a tiny bit. Now the problem has to be solved by the file reader, which also needs to determine whether the memory was read or written when there is an overlap between memory operands (MOVSD).

[torusrxxx]

x64dbg trace viewer reads comments and labels from the debug database, which can be modified after the trace was created. I thought about the case when you want to comment on a single iteration of a loop, and the conclusion was that a separate database could be created while leaving the original trace file unmodified. When the trace is large the comments could still be saved very fast without also re-saving the entire trace.

[teemu-l]

Hi torusrxxx.

I came to same conclusion about this. We should keep the saving fast and simple. Performance of the tracer is usually more important than the reader's. If anyone knows existing solution for determining the memory accesses, please let me know. I will fix this problem next month.

Saving comments and labels to separate database sounds good. I will take a look at the debug database file format.

Thanks