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