[all-commits] [llvm/llvm-project] 144d12: [lld] [MTE] Drop MTE globals for fully static exec...

[Mitch Phillips via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 144d127bef2cbe7a149a96a325390b0f52be51d3
      https://github.com/llvm/llvm-project/commit/144d127bef2cbe7a149a96a325390b0f52be51d3
  Author: Mitch Phillips <31459023+hctim at users.noreply.github.com>
  Date:   2023-10-10 (Tue, 10 Oct 2023)

  Changed paths:
    M lld/ELF/Driver.cpp
    M lld/ELF/InputFiles.cpp
    M lld/ELF/Writer.cpp
    M lld/ELF/Writer.h
    M lld/test/ELF/Inputs/aarch64-memtag-globals.s
    M lld/test/ELF/aarch64-memtag-globals.s

  Log Message:
  -----------
  [lld] [MTE] Drop MTE globals for fully static executables, not ban (#68217)

Integrating MTE globals on Android revealed a lot of cases where
libraries are built as both archives and DSOs, and they're linked into
fully static and dynamic executables respectively.

MTE globals doesn't work for fully static executables. They need a
dynamic loader to process the special R_AARCH64_RELATIVE relocation
semantics with the encoded offset. Fully static executables that had
out-of-bounds derived symbols (like 'int* foo_end = foo[16]') crash
under MTE globals w/ static executables. So, LLD in its current form
simply errors out when you try and compile a fully static executable
that has a single MTE global variable in it.

It seems like a much better idea to simply have LLD not do the special
work for MTE globals in fully static contexts, and to drop any
unnecessary metadata. This means that you can build archives with MTE
globals and link them into both fully-static and dynamic executables.