DW_TAG_subprogram in LLVM pass


When I used the llvm-dwarfdump -debug-info to analysis the LLVM bitcode. I could observe that different DW_TAG_subprogram may have different attributes. For example, some DW_TAG_subprogram may have the DW_AT_low_pc while others don’t.

I want to write a LLVM pass to check whether a function has the debug information, which means there is a DW_TAG_subprogram corresponding to the function. If so, I want to check whether the subprogram contains the attribute like DW_AT_low_pc.

I guess the information may be obtained from the Function.getSubprogram(). But I didn’t found the target API. Do you have any ideas? Many Thanks


Hi Muhui,

DWARF has two ways to describe the instructions associated with a subprogram. One is DW_AT_low_pc, usually paired with DW_AT_high_pc. The other is DW_AT_ranges.

These attributes are not represented in the IR metadata; they are emitted in the AsmPrinter phase, after code generation is complete. So, if you see a DW_TAG_subprogram, and that subprogram is defined in the compilation unit, then the DW_TAG_subprogram should (usually) have an attribute pointing to the instructions.

One exception is when the subprogram has been inlined. In that case, there is an “abstract” DW_TAG_subprogram that does not have DW_AT_low_pc or DW_AT_ranges; instead, for each inlined instance, there will be a DW_TAG_inlined_subroutine entry that has the instruction addresses for that inlined instance.

Another exception can arise when the subprogram is potentially generated in more than one compilation unit. For example, if the function is a C++ template function, or method of a template class. In that case the compiler cannot be sure whether any given subprogram will be defined in a different compilation unit, so it provisionally emits the code using ‘linkonce’ linkage (sometimes called COMDAT). When this happens, the linker will eliminate duplicates, and resolve all references to the subprogram to a single remaining copy. However, the DWARF descriptions of eliminated copies might still have dangling references, which then tend to be filled in with zeros rather than the final subprogram address. So, this is a case where DW_AT_low_pc could be present but not point to the actual instructions.

For completeness: If a DW_TAG_subprogram describes a function declaration, rather than a definition, it will not have instruction addresses in the DWARF entry; however this case is easy to identify because you will find the DW_AT_declaration flag instead.

Hope this helps,