Jarkko Sakkinen
jarkko
1. Out-of-line instance of an inlined subroutine.
2. Concrete instance of an inlined subroutine.
What is their difference put in some common sense terms? I'm dealing at work with a custom DWARF post-processor and have a hunch that grabbing this would help me to sort out a bug that I'm dealing with.
#DWARF #GCC #LLVM
1
0
1
1. DW_TAG_subprogram: contains data to connect tag to the source file locations of a function implemention.
2. DAW_TAG_inlined_subroutine: open coded (inlined) subprogram. Probably can be also for inlined subprogram (by optimizer or something) without DW_AT_inline set to 1. Contains offset in debug_info in the attribute DW_AT_abstract_origin referring to the subprogram that is inlined.
3. Out-of-line inlined subroutines have entry points i.e. are like clones of functions. They are tagged as DW_TAG_subprogram but have DW_AT_abstract_origin containing the reference to the root subprogram.
Something along lines of this....
2
0
0
<0x491fc>: Abbrev Number: 51 (DW_TAG_inlined_subroutine)
DW_AT_abstract_origin [DW_FORM_ref4] : <0x4cab0>
DW_AT_low_pc [DW_FORM_addr] : 0x0
DW_AT_high_pc [DW_FORM_data4] : 0
DW_AT_call_file [DW_FORM_data1] : 6
DW_AT_call_line [DW_FORM_data1] : 232
DW_AT_call_column [DW_FORM_data1] : 38
Origin:
<0x4cab0>: Abbrev Number: 36 (DW_TAG_subprogram)
DW_AT_linkage_name [DW_FORM_strp] : (indirect string, .debug_str+0x0): PRIME_VALIDATOR_DATA
DW_AT_name [DW_FORM_strp] : (indirect string, .debug_str+0x0): PRIME_VALIDATOR_DATA
DW_AT_decl_file [DW_FORM_data1] : 27
DW_AT_decl_line [DW_FORM_data1] : 247
DW_AT_type [DW_FORM_ref4] : <0xe9d>
DW_AT_inline [DW_FORM_data1] : 1
Files matching numbers can be found for instance llvm-dwarfdump -debug-line <file>
1
0
0
Farce Majeure
vathpela@better.boston
@jarkko it's just the section interleaving changing for every new feature that drives me nuts.
1
0
1
At least it was a jump start to a new job :-)
Spent literally few nights with the spec, code and not understanding anything at all but now I got some grip how to analyze it :-)
Of tools my experience is this so far:
- drarfdump and llvm-dwarfdump work with somewhat variable success rate unless the arch is something established as x86.
- readelf --debug-dump=<sections> can be worth of trying because it can sometimes succeed where dwarfdump fails.
- Of all tools the only tool that has pretty much nailed any file I've thrown to it has been rz-bin: https://book.rizin.re/src/tools/rz-bin/intro.html.
It is actually topic still that I would want be knowledgeable of, so no complains. Kind of spot in binary I've been too scared to touch before :-)
0
0
0
Omar Sandoval
osandov@fosstodon.org@jarkko another way to think of it is:
If the function isn't inlined anywhere, then it just has a DW_TAG_subprogram entry containing all of the information.
If it is inlined, then it still has a DW_TAG_subprogram entry containing variable names, source locations, etc. (the abstract instance), and it also has a DW_TAG_inlined_subroutine entry at each call site where it is inlined (the concrete instances).
1/2
1
0
2
Omar Sandoval
osandov@fosstodon.org@jarkko Additionally, if it is inlined anywhere AND a normal function was emitted (e.g., because it is not static or it is used via a function pointer), there is another DW_TAG_subprogram containing variable locations, call frame information, etc. (the concrete out-of-line instance).
I actually just had to fix a bug in drgn regarding out-of-line instances: https://github.com/osandov/drgn/issues/147
2/2
1
0
2
1
0
2
Omar Sandoval
osandov@fosstodon.org@jarkko I'm happy to answer questions about DWARF that you or anyone else encounter in the future!
0
0
2