summaryrefslogtreecommitdiffstats
path: root/llvm/test/tools/llvm-objcopy/ELF/cross-arch-sections-symbols.test
Commit message (Collapse)AuthorAgeFilesLines
* [yaml2obj][obj2yaml] - Change how symbol's binding is descibed when ↵George Rimar2019-04-031-10/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | parsing/dumping. Currently, YAML has the following syntax for describing the symbols: Symbols: Local: LocalSymbol1: ... LocalSymbol2: ... ... Global: GlobalSymbol1: ... Weak: ... GNUUnique: I.e. symbols are grouped by their bindings. That is not very convenient, because: It does not allow to set a custom binding, what can be useful for producing broken/special outputs for test cases. Adding a new binding would require to change a syntax (what we observed when added GNUUnique recently). It does not allow to change the order of the symbols in .symtab/.dynsym, i.e. currently all Local symbols are placed first, then Global, Weak and GNUUnique are following, but we are not able to change the order. It is not consistent. Binding is just one of the properties of the symbol, we do not group them by other properties. It makes the code more complex that it can be. This patch shows it can be simplified with the change performed. The patch changes the syntax to just: Symbols: Symbol1: ... Symbol2: ... ... With that, we are able to work with the binding field just like with any other symbol property. Differential revision: https://reviews.llvm.org/D60122 llvm-svn: 357595
* [llvm-objcopy] - Calculate the string table section sizes correctly.George Rimar2019-03-181-1/+1
| | | | | | | | | | | | | | This fixes the https://bugs.llvm.org/show_bug.cgi?id=40980. Previously if string optimization occurred as a result of StringTableBuilder's finalize() method, the size wasn't updated. This hopefully also makes the interaction between sections during finalization processes a bit more clear. Differential revision: https://reviews.llvm.org/D59488 llvm-svn: 356371
* [llvm-objcopy] Handle -O <format> flag.Jordan Rupprecht2019-01-071-0/+153
Summary: The -O flag is currently being mostly ignored; it's only checked whether or not the output format is "binary". This adds support for a few formats (e.g. elf64-x86-64), so that when specified, the output can change between 32/64 bit and sizes/alignments are updated accordingly. This fixes PR39135 Reviewers: jakehehrlich, jhenderson, alexshap, espindola Reviewed By: jhenderson Subscribers: emaste, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D53667 llvm-svn: 350541
OpenPOWER on IntegriCloud