Compatibility Notes

(c) Copyright 2002-2005 HEWLETT-PACKARD COMPANY
(c) Copyright 2002-2005 Massachusetts Institute of Technology

Here we describe any changes in our release that are not backward-compatible with prior releases. For a full list of changes see the changelog.

Compatibility of Version 0.9.4 with Prior Releases

Since we removed the filter library on Linux, the old dynamorio script will fail looking for libdrprivate.so. The new script will fail executing with the old library, as it will fail to load libdrprivate.so.

Since our adaptive working set cache sizing algorithm (see Derek Bruening's PhD thesis, Section 6.3.3) is enabled by default, there will be deletion of fragments during normal operation. If your client depends on deletions only occuring when driven by application operations such as code modifications, disable this feature with the -cache_regen 0 runtime option.

We changed the dr_replace_fragment() routine to delete the InstrList passed in, rather than the caller doing so, due to the possible delay in replacement. Thus, the caller must clone() the InstrList in order to keep a copy around.

The Linux GUI has not been updated and may not run on every Linux distribution due to shared library dependences.



Compatibility of Version 0.9.3 with Prior Releases

In Version 0.9.3., we made a number of changes to our interface that are not backward-compatible with prior releases (0.9.2 and earlier). The changes most likely to affect existing clients are discussed here. For a full list of changes see the changelog.

Instruction Interface Changes

We have added full adaptive level of detail support for instructions. The previous release decoded both basic block and trace InstrLists up to Level 3 before passing them to the client. Now, to give the client control, we pass the list as is, which is usually Level 0 with control transfer instructions at Level 3. Most of the time, an instruction will be auto-magically upgraded to the appropriate level if information is asked of it. This is only not true for the transition between Level 0 and Level 1. The reason is that that transition needs a context --- an InstrList --- to perform the instruction separation. The Level 0 to Level 1 transition must be explicitly performed. In fact,

instr_get_{opcode,src,dst,target} and instr_num_{srcs,dsts} WILL FAIL WHEN PASSED A LEVEL 0 INSTRUCTION!
This applies to routines that call these, as well -- for example, instr_is_cti calls instr_get_opcode. In general, instr_is routines require the opcode. There are a few exceptions, and they are documented as such: instr_is_exit_cti, instr_is_cti_short, and instr_is_cti_short_rewrite.

When passed Level 1 or above, these routines they will auto-magically upgrade the instruction to the appropriate level (Level 2 if the opcode is required, or Level 3 if operands are required).

To handle Level 0 instructions, they must be expanded into a series of Level 1 instructions using either instr_expand or the expanding iterator:

Here is a sample for loop using the expanding iterator:
    for (instr = instrlist_first_expanded(drcontext, bb);
	 instr != NULL;
	 instr = instr_get_next_expanded(drcontext, bb, instr))
Another expander is instrlist_decode_cti, which performs expansion plus decode_cti on all routines, and additionally hooks up cti's with Instr targets to each other. Once all instructions are expanded, all other Level upgrades are handled auto-magically.

Trace Dumps

-dump_traces is split into -tracedump_binary and -tracedump_text. -dump_trace_origins is renamed -tracedump_origins, and is now independent of normal trace dump, so you can get just the origins and not the trace body. The binary trace dump format is described here.

-prof_counts and -prof_times do NOT automatically select trace dumping, you have to do it yourself (and pick text or binary).

Indirect Branch Handling

The code transformation used for indirect branches has changed. The eflags are no longer saved around indirect branches inlined in traces, or prior to indirect branches in basic blocks. For the inline comparison in a trace, an obscure sequence of IA-32 instructions is used that does not modify the eflags.

If your client performs pattern recognition to identify indirect branches, the pattern will have to be updated. In the future we plan to use annotations to make it easier for clients to identify patterns and to avoid breaking clients every time we come up with better code transformations.

Logging

Thread-private log files are now used, kept in a dynamorio.NNN directory which is per-address-space. Notification messages about where the log files are are only printed to stderr if the -notify runtime option is supplied.

Minor API Changes



Documentation Home