Oops 和 objdump 中的 linux 内核函数长度（反汇编）

Question

I have some kernel Oops which failed here:

BUG: ...
IP: [<ffffffffabcdefab>] myfunction+0x10/0x1e [mymodule]

In Oops we can see that the function length is 30 bytes in decimal.
I suppose that length is amount of bytes from 1st byte of 1st instruction till 1st byte of last instruction . Ie scatter from 1st instruction's address till last instruction's address. Am I right?

So how could one ensure that myfunction is 30 bytes length viewing objdump output? Just subtracting address of 1st instruction from address of the last one?

Fe:

0000000000068930 <myfunction>:
   68930: 53                       push   %rbx   
   68931: 48 8b 07                 mov    (%rdi),%rax
   68934: 48 89 fb                 mov    %rdi,%rbx
   68937: ff 10                    callq  *(%rax)
   68939: 80 7b 08 00              cmpb   $0x0,0x8(%rbx)
   6893d: 75 09                    jne    68948 <foo1+0x20>
   6893f: 5b                       pop    %rbx   
   68940: c3                       retq
   68941: 0f 1f 80 00 00 00 00     nopl   0x0(%rax)
   68948: 48 89 df                 mov    %rbx,%rdi
   6894b: 5b                       pop    %rbx   
   6894c: eb a2                    jmp    688f0 <foo2>
   6894e: 66 90                    xchg   %ax,%ax

Can we tell that myfunction 's length is 0x6894e - 0x68930 = 1e (30 bytes in decimal) from output of objdump ? If no, what is the length of function in terms of disassembly?

Answer 1

It should really be the number of bytes from the beginning of the first instruction, to the end of the last instruction, inclusive. This is equivalent to taking the address of the byte after the last instruction, and subtracting the address of the first byte of the first instruction.

In this case, the last instruction of your function is actually the jmp 688f0 which begins at 6894c , and so the byte following this instruction is at 6894e . The xchg %ax, %ax instruction is not really part of your function; note that it isn't reachable from anywhere in your function. It's a no-op instruction that's been added by the compiler as padding, so that the next function can be aligned on an 8- or 16-byte boundary (which is better for caching, etc).