debugging - Avoiding source-level "jumping around" in gdb -


with c++ code built debugging g++ (i.e. options "-o0 -ggdb") , using newest gcc (5.1.0) , gdb (7.9) display of source code in gdb still painfully non-linear when using "next" command. example function call might expected step through single "next":

7757|   sdvalue newroot = tli->lowerformalarguments( 7758|      dag.getroot(), f.getcallingconv(), f.isvararg(), ins, dl, dag, invals); 

however takes four, displayed execution line being first 7757, 7758, again 7757, again 7758. if function call condensed single line 1 "next" needed. if call absurdly inflated 7 "next"s needed (shown '#' annotations)

       7757|   sdvalue        7758| newroot        7759| =   #1,6 7760| tli        7761| ->        7762| lowerformalarguments(     #5 7763|       dag.getroot(),        7764| f.getcallingconv(),     #3 7765| f.isvararg(),        7766| ins,        7767| dl,        7768| dag,        7769| invals #2,4,7 7770| ); 

so it's related not simple "each function call on distinct line stepping point". gets confusing breakpoints in recursive functions, find myself checking callstack see whether it's new invocation or phony backwards step.

since reflowing of llvm source contain function calls in single line isn't viable option, there gcc/gdb option controlling behaviour?

edit: checked clang 3.5 , lldb 3.5: when built clang 3 "next"s occur. , gdb , lldb see same "next" behaviour in either case (i.e. 4 gcc, 3 clang)

this sort of behavior debugger "gigo" situation -- is, gdb doing whatever debug info tells do. is, when there odd behavior, due decisions made compiler. may bug, , worth bug report, wouldn't surprised if intended work way reason.

you can investigate these kinds of problems using readelf or objdump examine line table.


Comments

Popular posts from this blog

php - failed to open stream: HTTP request failed! HTTP/1.0 400 Bad Request -

java - How to filter a backspace keyboard input -

java - Show Soft Keyboard when EditText Appears -