[PATCH] D6379: Only warn about DWARF2 supporting one section per compilation unit for code sections

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Mar 23 10:55:52 PDT 2020


dblaikie added a comment.

In D6379#1936534 <https://reviews.llvm.org/D6379#1936534>, @ostannard wrote:

> It looks like the issues this is warning about isn't the `.debug_line` section, but the `DW_AT_low/high_pc` attributes of the compilation unit DIE. With DWARF3 we can emit a DW_AT_ranges attribute instead, but that didn't exist in DWARF2.
>
> Since this range should only cover PC values corresponding to this compilation unit, maybe we could also limit this warning to sections with `SHF_EXECINSTR`?


Do you have examples where that's not already the case?

> Does linux tend to split code across multiple sections, or are the extra sections just used for data?

Yes, in object files - comdat sections are used for inline functions (or in the more extreme case, -ffunction-sections splits every function into its own .text section). Those all get linked into one section by the linker, but at the object file stage there are often multiple .text sections (maybe with unique name suffixes, maybe not (-fno-unique-section-names)).

Try compiling this at -O0:

  inline void f1() { }
  void f2()   f1(); }

or this with -ffunction-sections:

  void f1() { }
  void f2() { }

Oh, another way you can get holes in your CU address range even without distinct sections:

  void f1() { }
  __attribute__((nodebug)) void f1() { }
  void f3() { }


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D6379/new/

https://reviews.llvm.org/D6379





More information about the llvm-commits mailing list