Created attachment 13570 [details]
Binary to reproduce described bug with eu-addrline
For inlined code addr2line from binutils reports the function name of the inlined function. eu-addrline from elfutils, on the other hand, reports the function name of the function where the code was inlined (i.e. the caller). However, similar to addr2line, eu-addrline reports the file name of the file where the inlined code is defined. Which is very confusing as **the eu-addrline output reports a function name which is not defined in the reported file** for this reason.
Compare the following elfutils-0.185 and binutils-2.35 output for the attached RISC-V binary:
$ eu-addr2line -f -e inlined-bug.elf 20400e10
$ addr2line -f -e inlined-bug.elf 20400e10
The binutils output is correct, the irq_disable function is inlined at address 20400e10 (in the caller __atomic_fetch_and_4) and the irq_disable function is defined in /home/john/src/RIOT/cpu/riscv_common/include/irq_arch.h. The elfutils output on the other hand is confusing as __atomic_fetch_and_4 is not defined in /home/john/src/RIOT/cpu/riscv_common/include/irq_arch.h.
I noticed this while using dwfl_module_getsrc/dwfl_lineinfo/dwfl_module_addrname in my own code, the addr2line example just makes it easier to reproduce this issue. From a library standpoint I find it confusing how inlined functions are presently handled in libdwfl as it is often unclear if a libdwfl function returns information about the caller or the inlined function in such cases.