[PATCH] D61672: [llvm-objcopy] Allow strip symtab in executables and DSOs

Eugene Leviant via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon May 13 03:51:54 PDT 2019


evgeny777 marked an inline comment as done.
evgeny777 added a comment.

> I'm confused as to what this is trying to accomplish.

I'm trying to strip symtab, because it's not needed in executables. We have .dynsym for dynamic linker, but it is not even readed by llvm-objcopy, so all symbols are coming from .symtab

> This really just marks every symbol as unneeded in a DSO and keeps the behavior for other cases. In that case why not strip the symbol table all togethor? This is a very round about way to accomplish that.

This probably makes sense as well, but marking symbols unneeded seems more logical - one can figure out what is stripped looking at the single place in the code.

> Can you document exactly what behavior you're seeing?

GNU objcopy strips all symbols from  symtab in non-relocatable (ET_DYN or ET_EXEC) objects if those symbols are not referenced by relocations. 
My understanding is that in DSOs and executables all static relocations should have been resolved by static linker, so we shouldn't bother about them.
For details please look at `filter_symbols` function in `objcopy.c`



================
Comment at: tools/llvm-objcopy/ELF/ELFObjcopy.cpp:408
          is_contained(Config.UnneededSymbolsToRemove, Sym.Name)) &&
-        isUnneededSymbol(Sym))
+        (Obj.Type == ET_EXEC || Obj.Type == ET_DYN || isUnneededSymbol(Sym)))
       return true;
----------------
jhenderson wrote:
> What does GNU objcopy do for other ET_* types, e.g. ET_CORE or ET_* values in the OS and PROC-specific ranges? Could this be inverted to != ET_REL?
May be. GNU objcopy considers everything which is not ET_DYN or ET_EXEC relocatable. See filter_symbols in objcopy.c

```
  int relocatable = (abfd->flags & (EXEC_P | DYNAMIC)) == 0;
```




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

https://reviews.llvm.org/D61672





More information about the llvm-commits mailing list