[llvm-bugs] [Bug 43401] New: Issue with GOT section and static linking

via llvm-bugs llvm-bugs at lists.llvm.org
Sun Sep 22 11:33:59 PDT 2019


            Bug ID: 43401
           Summary: Issue with GOT section and static linking
           Product: lld
           Version: unspecified
          Hardware: Other
                OS: other
            Status: NEW
          Severity: normal
          Priority: P
         Component: ELF
          Assignee: unassignedbugs at nondot.org
          Reporter: eblot.ml at gmail.com
                CC: llvm-bugs at lists.llvm.org, peter.smith at linaro.org

Context: LLVM 9.0 (final), ARMv7em baremetal, C/C++, no shared libraries.

I'm having trouble using LLD to link a C++ application when some of LLVM's
libc++.a API is used, for example iostream.

I cannot reproduce the following issues with GNU LD, but it seems it does not
work the same way as LLD on this topic.

The initial issue is:
  ld.lld: error: no memory region specified for section '.got'

There is no .got section definition in many, if not most, ARM baremetal LD
scripts, and I do not understand why the compiler (LLVM Clang) generates such
sections with static libraries, as I understand .got sections are dedicated to
deal with shared libraries.

GNU LD automatically adds a `.got` section to the final ELF executable, even
when not specified in the linker script. Hence, this problem does not arise
with GNU LD.

Anyway, adding a `.got` section to the LLVM LLD linker script helps to some
point with features of libc++.a, but a new error arises when iostream API is
used. This error is:

  ld.lld: error: section: .got is not contiguous with other relro sections

I'm not fluent at all with RELRO and the like, but again it seems tightly
coupled to dynamic loading, which is far away from ARM baremetal static

I've been unable to find a way to workaround this issue, because:

1. existing baremetal ARM environments usually provides LD scripts which are
quite hard to wring them so they get compliant with what seems to be required
for LLD, if I understand the constraints expressed in

2. there is not dynamic loaded in a statically built environment, so it seems
the purpose of RELRO does not apply to this kind of environment

3. it is quite hard (without using a debugger against LLD) to figure out what
are the real constraints that trigger this error message, i.e. which section
has been considered as a RELRO candidate.

 1- Is it valid to consider .got sections for a statically linked, baremetal
 2- Is there a way to disable the unique, contiguous RELRO section checks?

If it is valid to consider .got and .relro sections for ARM statically linked
baremetal applications, is there a recommended approach to sort this out,
because for now, I have found no valid example on how to write a LLD-compliant
linker script for this environment while linking against libc++.a / libc++abi.a
static libraries.


You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190922/2536dcae/attachment.html>

More information about the llvm-bugs mailing list