Since updating to the LLVM v5.0 Final tag, I am seeing a crash when I enable ‘-g’. With a Debug build this hits an assertion at line #923 in ‘lib/CodeGen/AsmPrinter/DwarfDebug.cpp’:
assert(EndLabel && “Forgot label after instruction ending a range!”);
The values of related variables at this time are:
‘Begin’ is: DBG_VALUE %I23, %noreg, !“fp”, <!345>; line no:381
‘End’ is: DBG_VALUE %I19, 88, !“ap”, <!345>; line no:381 indirect
‘StartLabel’ is: .Ltmp327
‘I19’ is the stack-pointer, and it is the expression ‘EndLabel = getLabelAfterInsn(End)’ that is returning ‘nullptr’. This happens only when compiling ‘vfprintf.c’ or ‘vfwprintf.c’ from Newlib v2.5.0, and line #381 referenced is the location of the declaration of the function ‘_vfwprintf_r’. But our implementation does not directly do anything with Dwarf meta-data, so I don’t understand what we could be doing that would cause this.
Has this been seen before, and any suggestions on how I should debug this?
Here are a couple things I would try to help triangulate on the problem.
Try a vanilla upstream compiler for an in-tree target. (IIRC you have your own target.) If that fails, it’s pretty optimal for you because you should be able to reduce a test case and file a PR. If it doesn’t fail, that suggests it’s either something your target does or doesn’t do, or some bug in how you’ve done your adaptation to LLVM 5.0.
You can also try compiling with –S and assembling the result; I have seen that behave differently from direct object generation sometimes. If that’s the case here, it should be not terribly hard to work out how the paths are different.
Actually in my case (out of tree) I always compile to assembly. It does appear to crash only when my target is selected, I build the compiler with multiple targets enabled, and it does not crash for the other in-tree targets even with the same compiler binary. Strange, I can’t think of anywhere in my target that handle debug information explicitly.
Have to roll my sleeves up and go hunting