Check the DWARF format that I linked you to. The debug_* sections use an special automaton to create the debug information (instead of storing it in a great big table). The lines you mentioned are detailing what that automaton is doing (advancing the line pointer, from one value to another).
Thank you so much James.
The automation is too complex for me. I am rewriting the dwarf.c from binutils to java, so peter-bochs can support single step trace in C level. Wherever you loaded the ELF (kernel/app), bochs can single step trace on it. I think it is a great feature for os developer.
thanks
from Peter
mcheung63 wrote:Thank you so much James.
The automation is too complex for me. I am rewriting the dwarf.c from binutils to java, so peter-bochs can support single step trace in C level. Wherever you loaded the ELF (kernel/app), bochs can single step trace on it. I think it is a great feature for os developer.
thanks
from Peter
You won't manage that without grasping the concept of the automaton, because it's central to the DWARF standard!
I need to make bochs able to disassemble in any memory location, then peter-bochs can support c level single step trace. Very helpful to debug my os app
That's not so bad. Try porting a compiler to a new architecture, and you have reference code that you know does something important but you have no clue how it does it because of obscure variable names and macros so you're really trusting that it work and you see: