一直不太理解为什么汇编代码的地址不是连续的

0x083d002b <_ZN17CpCallmMptyCdrDef7setInfoEPhhhhh+347>: mov 0xc(%esi),%ecx
0x083d002e <_ZN17CpCallmMptyCdrDef7setInfoEPhhhhh+350>: lea 0xfffffff2(%ebp),%edx
0x083d0031 <_ZN17CpCallmMptyCdrDef7setInfoEPhhhhh+353>: mov %edx,0x10(%esp)
0x083d0035 <_ZN17CpCallmMptyCdrDef7setInfoEPhhhhh+357>: movl $0x14,0x8(%esp)
0x083d003d <_ZN17CpCallmMptyCdrDef7setInfoEPhhhhh+365>: mov %esi,0x4(%esp)

为什么地址从0x083d002b一下就到了0x083d002e？
遇到一个core dump的问题，trace back显示dump点是在地址0x083d0032。但是从反汇编的代码看根本没有这个地址。
其次，从info line *0x083d0032的情况看，显示对应的source code代码行在250行。但是用info line 250查到的汇编代码段却是从0x83d000f到0x83d0012？？

>> 为什么地址从0x083d002b一下就到了0x083d002e？
  这是因为 mov 0xc(%esi),%ecx 这个指令自身占用了 3 个字节的空间。

后面的两个问题，对你这个环境没接触过，不了解。是地址偏移的问题？两边的语句和指令对照下看看，应该能定位的。

我之前也是这么想的。一条指令占几个字节的空间。但是第三条指令同样是一个命令，两个操作数。但是第4挑指令的气势地址比第三条多了4个byte。第5条指令比第4条就多的更多了。所以不解？？

反汇编没有0x083d0032这个地址，说明指令不能从这里被断开，断开了么，估计程序跑飞或者产生了异常了

不是每个指令都是一样的长度的；相同的 mov 指令，由于源和目的操作数类型/寻址模式的不同，长度也会有不同；更具体的要看该指令的编码了，这个可以参考 intel 的开发手册 Vol2 指令集卷。

恩。谢谢。先去看看开发手册