[llvm-dev] [llvm-objdump] Bug 40703 - wrong line number info for obj file compiled with -ffunction-sections
David Blaikie via llvm-dev
llvm-dev at lists.llvm.org
Tue Feb 12 09:56:35 PST 2019
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)
On Tue, Feb 12, 2019 at 7:36 AM Alexey Lapshin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
> Folks,
>
> I would like to ask about *Bug 40703*
> <https://bugs.llvm.org/show_bug.cgi?id=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
> ======================================================
> index a41ab21412d..cea7aedc26a 100644
> --- a/llvm/include/llvm/DebugInfo/DIContext.h
> +++ b/llvm/include/llvm/DebugInfo/DIContext.h
> @@ -203,11 +203,11 @@ public:
> return true;
> }
>
> - virtual DILineInfo getLineInfoForAddress(uint64_t Address,
> + virtual DILineInfo getLineInfoForAddress(object::SectionedAddress
> Address,
> DILineInfoSpecifier Specifier = DILineInfoSpecifier()) = 0;
> - virtual DILineInfoTable getLineInfoForAddressRange(uint64_t Address,
> + virtual DILineInfoTable
> getLineInfoForAddressRange(object::SectionedAddress Address,
> uint64_t Size, DILineInfoSpecifier Specifier =
> DILineInfoSpecifier()) = 0;
> - virtual DIInliningInfo getInliningInfoForAddress(uint64_t Address,
> + virtual DIInliningInfo
> getInliningInfoForAddress(object::SectionedAddress Address,
> DILineInfoSpecifier Specifier = DILineInfoSpecifier()) = 0;
>
>
> include/llvm/DebugInfo/DWARF/DWARFDebugLine.h
> ======================================================
> - uint32_t lookupAddress(uint64_t Address) const;
> + uint32_t lookupAddress(llvm::SectionedAddress Address) const;
>
> - bool lookupAddressRange(uint64_t Address, uint64_t Size,
> + bool lookupAddressRange(llvm::SectionedAddress Address, uint64_t Size,
> std::vector<uint32_t> &Result) const;
>
> bool hasFileAtIndex(uint64_t FileIndex) const;
> @@ -238,7 +247,7 @@ public:
>
> /// Fills the Result argument with the file and line information
> /// corresponding to Address. Returns true on success.
> - bool getFileLineInfoForAddress(uint64_t Address, const char *CompDir,
> + bool getFileLineInfoForAddress(llvm::SectionedAddress Address, const
> char *CompDir,
> DILineInfoSpecifier::FileLineInfoKind
> Kind,
> DILineInfo &Result) const;
>
> - uint32_t lookupAddress(uint64_t Address) const;
> + uint32_t lookupAddress(llvm::SectionedAddress Address) const;
>
> include/llvm/DebugInfo/Symbolize/Symbolize.h
> ======================================================
> @@ -57,13 +57,13 @@ public:
> }
>
> Expected<DILineInfo> symbolizeCode(const std::string &ModuleName,
> - uint64_t ModuleOffset,
> + object::SectionedAddress
> ModuleOffset,
> StringRef DWPName = "");
> Expected<DIInliningInfo> symbolizeInlinedCode(const std::string
> &ModuleName,
> - uint64_t ModuleOffset,
> + object::SectionedAddress
> ModuleOffset,
> StringRef DWPName = "");
> Expected<DIGlobal> symbolizeData(const std::string &ModuleName,
> - uint64_t ModuleOffset);
> + object::SectionedAddress
> ModuleOffset);
>
>
> include/llvm/DebugInfo/Symbolize/SymbolizableModule.h
> ======================================================
> @@ -24,13 +24,13 @@ class SymbolizableModule {
> public:
> virtual ~SymbolizableModule() = default;
>
> - virtual DILineInfo symbolizeCode(uint64_t ModuleOffset,
> + virtual DILineInfo symbolizeCode(object::SectionedAddress ModuleOffset,
> FunctionNameKind FNKind,
> bool UseSymbolTable) const = 0;
> - virtual DIInliningInfo symbolizeInlinedCode(uint64_t ModuleOffset,
> + virtual DIInliningInfo symbolizeInlinedCode(object::SectionedAddress
> ModuleOffset,
> FunctionNameKind FNKind,
> bool UseSymbolTable) const
> = 0;
> - virtual DIGlobal symbolizeData(uint64_t ModuleOffset) const = 0;
> + virtual DIGlobal symbolizeData(object::SectionedAddress ModuleOffset)
> const = 0;
>
> If there are no objections for such interface change I would proceed with
> my fix in fabricator.
>
>
> Thank you, Alexey.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190212/51545824/attachment.html>
More information about the llvm-dev
mailing list