I use llvm and llvm-gcc as a C-to-C transformation tool using a
modified version of the c backend, and rely on llvm debug instructions
to link back to the original source code.
Does anyone know how to get detailed line number and variable debug
information at optimization levels beyond O0?
Currently, I extract this debug information by compiling with -g.
This works fine with "llvm-gcc -g -O0 --emit-llvm", i.e. no
optimizations, but when I enable optimizations, e.g. "llvm-gcc -g -O2
--emit-llvm",
most of the dbg.stoppoint and dbg.declare instructions dissapear.
I tried to enable at least debug.declare instructions by removing the
"if(optimize) return" statement in gcc/llvm-debug.cpp,
DebugInfo::EmitDeclare(), but I still do not get any dbg.declare
instructions.
Is there a way to keep all debug information with optimizations
enabled in llvm-gcc?
If I have to disable some specific optimizations to keep the debug
info correct that is fine.
I use llvm and llvm-gcc as a C-to-C transformation tool using a
modified version of the c backend, and rely on llvm debug instructions
to link back to the original source code.
Does anyone know how to get detailed line number and variable debug
information at optimization levels beyond O0?
Currently, I extract this debug information by compiling with -g.
This works fine with "llvm-gcc -g -O0 --emit-llvm", i.e. no
optimizations, but when I enable optimizations, e.g. "llvm-gcc -g -O2
--emit-llvm",
most of the dbg.stoppoint and dbg.declare instructions dissapear.
I tried to enable at least debug.declare instructions by removing the
"if(optimize) return" statement in gcc/llvm-debug.cpp,
DebugInfo::EmitDeclare(), but I still do not get any dbg.declare
instructions.
This will enable dbg.declare, but they'll be removed by mem2reg pass
immediately.
Is there a way to keep all debug information with optimizations
enabled in llvm-gcc?
If I have to disable some specific optimizations to keep the debug
info correct that is fine.
Without mem2reg pass, you're unlikely to get much optimization done on your IR.
I use llvm and llvm-gcc as a C-to-C transformation tool using a
modified version of the c backend, and rely on llvm debug instructions
to link back to the original source code.
Does anyone know how to get detailed line number and variable debug
information at optimization levels beyond O0?
Currently, I extract this debug information by compiling with -g.
This works fine with "llvm-gcc -g -O0 --emit-llvm", i.e. no
optimizations, but when I enable optimizations, e.g. "llvm-gcc -g -O2
--emit-llvm",
most of the dbg.stoppoint and dbg.declare instructions dissapear.
I tried to enable at least debug.declare instructions by removing the
"if(optimize) return" statement in gcc/llvm-debug.cpp,
DebugInfo::EmitDeclare(), but I still do not get any dbg.declare
instructions.
This will enable dbg.declare, but they'll be removed by mem2reg pass
immediately.
Is there a way to keep all debug information with optimizations
enabled in llvm-gcc?
If I have to disable some specific optimizations to keep the debug
info correct that is fine.
Without mem2reg pass, you're unlikely to get much optimization done on your IR.
Clear, thanks! I presume the mem2reg pass is also essential in the
CLang frontend, so CLang is not an alternative to llvm-gcc to keep
more debug information?
For the dbg.stoppoints: many of the stoppoint instructions dissapear
at higher optimization levels. We need these to link back instructions
to original C statements. I guess this is not related to the mem2reg
pass. Is there a way to at least keep the stoppoint instructions?
The llvm.dbg.value proposal looks very interesting. We would like to
contribute if possible. I estimate we do not have sufficient llvm
experience to contribute ourselves, but may take up a part of the work
using a contractor. Can you identify a clear part for which we could
hire a contractor?
Without mem2reg pass, you're unlikely to get much optimization done on your IR.
Clear, thanks! I presume the mem2reg pass is also essential in the
CLang frontend, so CLang is not an alternative to llvm-gcc to keep
more debug information?
Yes.
For the dbg.stoppoints: many of the stoppoint instructions dissapear
at higher optimization levels. We need these to link back instructions
to original C statements. I guess this is not related to the mem2reg
pass. Is there a way to at least keep the stoppoint instructions?
Good news. In mainline svn sources, llvm, llvm-gcc and clang, are not
using dbg.stoppoints. Now location info (line, column and scope) is
attached directly with llvm instructions. This way, the info is more
likely to survive through optimization passes. The optimizer may lose
info when it replaces one set of instructions with another set,
however that is now easier to track and fix. For example, inliner is
now appropriately coping info when it copies function body. This is a
recent development.
The llvm.dbg.value proposal looks very interesting. We would like to
contribute if possible. I estimate we do not have sufficient llvm
experience to contribute ourselves, but may take up a part of the work
using a contractor. Can you identify a clear part for which we could
hire a contractor?
This work can be largely divided into 3 phases.
1) Emit and preserve llvm.dbg.var intrinsic through target independent
optimization passes. This requires experience dealing with llvm
transformation passes. Victor Hernandez has started working on this
phase.
2) Lower llvm.dbg.var and preserve variable info through code
generation passes. This requires codegen familiarity.
3) Emit appropriate DWARF entries based on the variable info that
survives through optimization and codegen passes. DWARF knowledge is
useful here.
For the dbg.stoppoints: many of the stoppoint instructions dissapear
at higher optimization levels. We need these to link back instructions
to original C statements. I guess this is not related to the mem2reg
pass. Is there a way to at least keep the stoppoint instructions?
Good news. In mainline svn sources, llvm, llvm-gcc and clang, are not
using dbg.stoppoints. Now location info (line, column and scope) is
attached directly with llvm instructions. This way, the info is more
likely to survive through optimization passes. The optimizer may lose
info when it replaces one set of instructions with another set,
however that is now easier to track and fix. For example, inliner is
now appropriately coping info when it copies function body. This is a
recent development.
That is great news, somehow I overlooked this on the mailing list, my
bad. I will look into this asap.
1) Emit and preserve llvm.dbg.var intrinsic through target independent
optimization passes. This requires experience dealing with llvm
transformation passes. Victor Hernandez has started working on this
phase.
2) Lower llvm.dbg.var and preserve variable info through code
generation passes. This requires codegen familiarity.
3) Emit appropriate DWARF entries based on the variable info that
survives through optimization and codegen passes. DWARF knowledge is
useful here.
Our interest is only in the target independent part 1) since we use
something similar to the C backend, i.e. no codegen/dwarf.
If this is already work in progress, can we help out in testing
preliminary work?