weird sequences in trace files
hvdieren
I have come across some weird sequences in the trace files that trigger
my attention (because they ruin my branch prediction scheme :-). These
sequences contain instructions that occur immediately before a context
switch (assuming that addresses 0xcyyyyyyy belong to the OS).
E.g., in crafty, you can find this sequence:
0x8048c0d (conditional branch to 0x8048c17)
0x8048c1f (presumed unconditional branch to 0xc010c670)
... a bunch of 0xcyyyyyyy addresses that normally do not occur in this
procedure
... ending in 0xc01088cf jumping to 0xc01088d1
0x8048c1c !!! we jumped back in the program
I would like to have confirmed whether the instruction at 0x8048c1f
is really a branch. Judging from the traces it is not. I think these
are fake unconditional branches that result from the trace recording
tool. Maybe it's better to remove them.
Best,
Hans.
djimenez
You are right that the instruction at 0x8048c1f is not a branch; it is
the second byte in a register-register mov instruction. I have looked
through crafty at a lot of the transitions from 0x8xxxxxx to 0xcyyyyyyy
and they all have one thing in common: the 0x8xxxxxx instruction is an
instruction that refers to memory (either by branching or loading
data). It's almost certainly the case that these are page faults and
the page fault handler is being invoked. The tracing software is
apparently passing this exception through as a branch rather than
ignoring it as I intended. I'll take a look at the other traces and
see whether it's worth doing some more processing on the traces to
address this. In crafty, a transition from 0x8xxxxxx to 0xcyyyyyyy
occurs in 0.05% of the traces, so I expect the impact of this to be
minimal. Thanks for bringing it to my attention.
--
Daniel Jiménez