Hi,
I see this testcase occasionally failing. After reproducing it with
verbose output and checking objdump output I found at least 3 scenarios
where data read from objdump output does not match:
1. same byte is repeated in objdump output
Note that byte at ffffffff815cf071 is in output twice
ffffffff815cf06e <sysret_check+0x4b>:
ffffffff815cf06e: 24 2f and $0x2f,%al
ffffffff815cf070: 00 0f add %cl,(%rdi)
ffffffff815cf071 <sysret_careful>:
ffffffff815cf071: 0f ba e2 03 bt $0x3,%edx
ffffffff815cf075: 73 11 jae
2. objdump output can span across multiple sections
For example in case of libcrc32c.ko and start_address=8 .text
sections ends at 6b, but test continues to read output from
.init.text:
Disassembly of section .text:
0000000000000008 <crc32c+0x8>:
8: 48 89 e5 mov %rsp,%rbp
b: 53 push %rbx
c: 8b 01 mov (%rcx),%eax
...
6b: 90 nop
Disassembly of section .init.text:
0000000000000008 <init_module+0x8>:
8: 00 00 add %al,(%rax)
a: 00 00 add %al,(%rax)
c: 48 89 e5 mov %rsp,%rbp
3. gaps in output
For example, note that byte at ffffffff81670500 is missing:
ffffffff816704fe <sysret_check+0x4b>:
ffffffff816704fe: 7b 34 jnp ffffffff81670534 <sysret_signal+0x1c>
...
ffffffff81670501 <sysret_careful>:
ffffffff81670501: 0f ba e2 03 bt $0x3,%edx
ffffffff81670505: 73 11 jae ffffffff81670518 <sysret_signal>
My idea to fix this (attached) was to change objdump output reading
from sequential to offset-based - to take into account offset of
each line. And if offset starts going backwards, stop reading.
Comments/other ideas are welcome.
Regards,
Jan