linux内核模块call trace格式解析

今天测试编写的内核模块进行文件读写，结果失败。通过dmesg查看内核输出，结果如下：

[37725.645804] I am here! and the user buf size is 1024
[37725.645812] The last data record position: 4096
                current postion:0
[37725.645818] buff size 8
[37725.647660] BUG: unable to handle kernel paging request at 0000000001955600
[37725.647690] IP: mid+0xc/0x80 [episode]
[37725.647696] PGD 8000000009f8b067 P4D 8000000009f8b067 PUD 4df81067 PMD e0f8067 PTE 8000000090fa0867
[37725.647711] Oops: 0001 [#1] SMP PTI
[37725.649451] Modules linked in: episode(OE) rfcomm bnep coretemp crct10dif_pclmul crc32_pclmul snd_ens1371 snd_ac97_codec ghash_clmulni_intel gameport ac97_bus snd_pcm pcbc snd_seq_midi snd_seq_midi_event aesni_intel aes_x86_64 vmw_balloon crypto_simd glue_helper cryptd intel_rapl_perf snd_rawmidi input_leds joydev serio_raw btusb btrtl btbcm snd_seq snd_seq_device snd_timer btintel bluetooth snd ecdh_generic soundcore shpchp i2c_piix4 vmw_vsock_vmci_transport mac_hid vsock vmw_vmci binfmt_misc parport_pc ppdev lp parport autofs4 hid_generic usbhid hid psmouse vmwgfx ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ahci drm mptspi libahci mptscsih mptbase e1000 scsi_transport_spi pata_acpi [last unloaded: episode]
[37725.649732] CPU: 0 PID: 17208 Comm: a.out Tainted: G           OE    4.15.0-72-generic #81~16.04.1-Ubuntu
[37725.649739] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015
[37725.649761] RIP: 0010:mid+0xc/0x80 [episode]
[37725.649768] RSP: 0018:ffffb94ac5697e28 EFLAGS: 00010246
[37725.649777] RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000004
[37725.649783] RDX: 0000000000000000 RSI: 0000000001955600 RDI: ffffb94ac5697e5c
[37725.649789] RBP: ffffb94ac5697e90 R08: 0000000000000001 R09: 00000000000008cd
[37725.649795] R10: ffff8e9a5a8ff180 R11: 00000000000008cd R12: 0000000000000000
[37725.649801] R13: 0000000000000000 R14: 0000000000000000 R15: ffff8e9a5a8ff180
[37725.649809] FS:  00007f7c95277700(0000) GS:ffff8e9afa600000(0000) knlGS:0000000000000000
[37725.649814] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[37725.649820] CR2: 0000000001955600 CR3: 000000000f48e003 CR4: 00000000003606f0
[37725.650020] Call Trace:
[37725.651102]  ? episode_direct_write+0x13a/0x220 [episode]
[37725.652434]  __vfs_write+0x1b/0x40
[37725.652458]  vfs_write+0xb8/0x1b0
[37725.652467]  ? do_sys_open+0x1b4/0x290
[37725.652477]  SyS_write+0x5c/0xe0
[37725.653225]  do_syscall_64+0x73/0x130
[37725.653859]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2

上面是截取的一段内容。最后面的call trace显示了出错的地方的调用过程。

其中最后出错在episode_direct_write函数。出错的地方在0x13a，这里指的是episode_direct_write编译成机器码后的长度为0x220字节中的位置0x13a。

但要想确认到底错在哪里了，就比较麻烦了。因为我不知道编译成的机器码长什么样，即使知道了，我可能也看不懂啊。

对于以下例子：

Call Trace:
 [<123>] a+0x8/0x10
[<234>] b+0x0/0x10

a具体出错的函数，0x10是a编译成机器码后的长度，0x8是出错的指令在a里的偏移。