distorm | Powerful Disassembler Library For x86/AMD64

I'm trying to validate and understand the instructions executed in a simulation framework. The simulation steps are the following:

1. a binary is cross-compiled in a host x86 machine with gcc (with -fPIC flag)
2. the binary is then moved and executed in a virtual machine x86 named SimNow (used by AMD for testing their processors)
3. the SimNow machine produces a list of executed instructions which they are passed to a framework including information about each instruction: virtual address, physical address, size, opcode.
4. the framework produces a trace of the executed instructions including mnemonic and operands thanks to a x86 disassembler (named distorm). This is an example of trace output:

The list of executed instructions includes the instructions contained into the binary and possible kernel instructions.

I'm validating the user instructions of the trace by using the ouput of the objdump on the binary. They are equal, confirming the correctness of the execution.

This is the objdump output for the instructions in the previous picture:

For kernel instructions, I had to apply preliminary steps:

1. I installed the kernel headers into the virtual machine and I extracted the linux image for executing the objdump on it.
2. I added the kernel symbols into the trace output by comparing the virtual address of the kernel instruction with the virtual address contained in /proc/kallsysms.

For the validation step, I'm using the same methodology of the user instructions, comparing the objdump of the linux kernel image with the trace output. However, I noticed some differences...mostly when a kernel symbol instruction is discovered. This is the output of the trace:

This is the correspondent section of the linux kernel image:

As you can see from these pictures, each callq which corresponds to a kernel symbol (comparing the virtual address of the linux image with /proc/kallsyms) is substituted with a NOP DWORD (nopl instruction) in trace output.

What I'm trying to do is understand why there is a NOP DWORD instead of callq for the kernel symbols.

It happens due to the relocation? If yes, how can I reconstruct the relocation for such instructions?

NOTE: I executed objdump with -dr for checking the relocation on the Linux image, but the output didn't change.

My validation methodology is wrong for kernel instructions?