[llvm-objdump] Bug 40703 - wrong line number info for obj file compiled with -ffunction-sections

Folks,

I would like to ask about Bug 40703 - wrong line number info for obj file compiled with -ffunction-sections. The problem there is that when object file compiled, it does not have addresses assigned to sections. So it uses offsets inside section to dump instructions. When these offsets came to DwarfLineTable(to get line information) - it does not know which section it relates to. I have a fix for that bug. I believe correct fix would be to pass additional section information. But it changes interfaces and need to patch many places. I would like to ask whether these interface changes are OK. The main change is to pass not only address but corresponding Section Index also:

struct SectionedAddress {
uint64_t Address;
uint64_t SectionIndex;
};

include/llvm/DebugInfo/DIContext.h

Using a SectionedAddress instead of a raw address makes sense to me.

Some side notes on the bug/issue (partly as exposition for other readers of this thread):

This shows up only for objects, I think (not linked executables - because then all the executable code is in one section anyway).

This isn’t unique to using function-sections. It applies to any object with more than one .text section, which is common in C++ for any inline functions. eg:
inline void f1() { }
void f2() { f1(); }
$ clang++ x.cpp -g -c && llvm-objdump --disassemble --line-numbers x.o
_Z2f2v:
; /usr/local/google/home/blaikie/dev/scratch/inl.cpp:2

; /usr/local/google/home/blaikie/dev/scratch/inl.cpp:1

Disassembly of section .text._Z2f1v:
_Z2f1v:
; /usr/local/google/home/blaikie/dev/scratch/inl.cpp:2

; /usr/local/google/home/blaikie/dev/scratch/inl.cpp:1

(whereas binutils objdump prints line 2 for f2 and line 1 for f1)