[all-commits] [llvm/llvm-project] 86478d: [MC][ELF] Put explicit section name symbols into e...

bd1976bris via All-commits all-commits at lists.llvm.org
Thu Apr 16 12:13:23 PDT 2020


  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 86478d3de91a81978c2c310fda13f04541cd3b23
      https://github.com/llvm/llvm-project/commit/86478d3de91a81978c2c310fda13f04541cd3b23
  Author: bd1976llvm <Ben.Dunbobbin at sony.com>
  Date:   2020-04-16 (Thu, 16 Apr 2020)

  Changed paths:
    M clang/test/CodeGen/cfstring-elf-sections-x86_64.c
    M llvm/include/llvm/IR/DiagnosticInfo.h
    M llvm/include/llvm/MC/MCContext.h
    M llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
    M llvm/lib/MC/MCContext.cpp
    A llvm/test/CodeGen/X86/explicit-section-mergeable.ll
    M llvm/unittests/ExecutionEngine/Orc/LegacyRTDyldObjectLinkingLayerTest.cpp
    M llvm/unittests/ExecutionEngine/Orc/RTDyldObjectLinkingLayerTest.cpp

  Log Message:
  -----------
  [MC][ELF] Put explicit section name symbols into entry size compatible sections

Ensure that symbols explicitly* assigned a section name are placed into
a section with a compatible entry size.

This is done by creating multiple sections with the same name** if
incompatible symbols are explicitly given the name of an incompatible
section, whilst:

  - Avoiding using uniqued sections where possible (for readability and
    to maximize compatibly with assemblers).

  - Creating as few SHF_MERGE sections as possible (for efficiency).

Given that each symbol is assigned to a section in a single pass, we
must decide which section each symbol is assigned to without seeing the
properties of all symbols. A stable and easy to understand assignment is
desirable. The following rules facilitate this: The "generic" section
for a given section name will be mergeable if the name is a mergeable
"default" section name (such as .debug_str), a mergeable "implicit"
section name (such as .rodata.str2.2), or MC has already created a
mergeable "generic" section for the given section name (e.g. in response
to a section directive in inline assembly). Otherwise, the "generic"
section for a given name is non-mergeable; and, non-mergeable symbols
are assigned to the "generic" section, while mergeable symbols are
assigned to uniqued sections.

Terminology:
"default" sections are those always created by MC initially, e.g. .text
or .debug_str.

"implicit" sections are those created normally by MC in response to the
symbols that it encounters, i.e. in the absence of an explicit section
name assignment on the symbol, e.g. a function foo might be placed into
a .text.foo section.

"generic" sections are those that are referred to when a unique section
ID is not supplied, e.g. if there are multiple unique .bob sections then
".quad .bob" will reference the generic .bob section. Typically, the
generic section is just the first section of a given name to be created.
Default sections are always generic.

* Typically, section names might be explicitly assigned in source code
using a language extension e.g. a section attribute: _attribute_
((section ("section-name"))) -
https://clang.llvm.org/docs/AttributeReference.html

** I refer to such sections as unique/uniqued sections. In assembly the
", unique," assembly syntax is used to express such sections.

Fixes https://bugs.llvm.org/show_bug.cgi?id=43457.

See https://reviews.llvm.org/D68101 for previous discussions leading to
this patch.

Some minor fixes were required to LLVM's tests, for tests had been using
the old behavior - which allowed for explicitly assigning globals with
incompatible entry sizes to a section.

This fix relies on the ",unique ," assembly feature. This feature is not
available until bintuils version 2.35
(https://sourceware.org/bugzilla/show_bug.cgi?id=25380). If the
integrated assembler is not being used then we avoid using this feature
for compatibility and instead try to place mergeable symbols into
non-mergeable sections or issue an error otherwise.

Differential Revision: https://reviews.llvm.org/D72194




More information about the All-commits mailing list