[PATCH] D117233: [llvm-objcopy] Preserve ARM and AArch64 mapping symbols

Peter Smith via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 13 10:37:34 PST 2022


peter.smith added a comment.

>From https://sourceware.org/binutils/docs/binutils/objcopy.html

  -x
  --discard-all
  Do not copy non-global symbols from the source file.
  
  -X
  --discard-locals
  Do not copy compiler-generated local symbols. (These usually start with ā€˜Lā€™ or ā€˜.ā€™.)
  --strip-unneeded
  Remove all symbols that are not needed for relocation processing in addition to debugging symbols and sections stripped by --strip-debug.

Empirically with arm-none-eabi-objcopy from binutils 2.35 and aarch64-linux-gnu-objcopy from binutils 2.34 I get the same results:

| filetype/option | --discard-locals          | --discard-all             | --strip-unneeded                |
| object          | mapping symbols preserved | mapping symbols preserved | mapping symbols preserved       |
| executable      | mapping symbols preserved | mapping symbols removed   | all non dynamic symbols removed |
|

I would expect mapping symbols to be preserved in local objects when doing these transformations. They are required in AArch32 for the following things:

- Denoting Arm/Thumb changes mid-function (assembly) and constant pools (needed for disassembly)
- Linker patching (effectively linker needs to disassemble the code accurately)
- big-endian output (linker needs to endian revers instructions but not constant pools). This is not supported in LLD right now.

LLD uses mapping symbols in https://github.com/llvm/llvm-project/blob/main/lld/ELF/ARMErrataFix.cpp#L316 for linker patching.

In AArch64 in practice mapping symbols are only needed if someone has used constant pools in assembly language. In LLD we account for that case in linker patching for https://github.com/llvm/llvm-project/blob/main/lld/ELF/AArch64ErrataFix.cpp#L430

For executables they are only used for disassembly. I guess --discard-locals could still keep them based on the GNU documentation entry.

Not had a chance to look at the implementation here. I'm broadly in favour with matching the GNU tools behaviour.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117233



More information about the llvm-commits mailing list