Before this patch we gave a priority to a dynamic table found
from the section header.
It was discussed (here: https://reviews.llvm.org/D67078?id=218356#inline-602082)
that probably preferring the table from PT_DYNAMIC is better,
because it is what runtime loader sees.
This patch makes the table from PT_DYNAMIC be chosen at first place if it is available.
But also it adds logic to fall back to SHT_DYNAMIC if the table from the dynamic segment is
broken or fall back to use no table if both are broken.
It adds a few more diagnostic warnings for the logic above.
Differential revision: https://reviews.llvm.org/D67547
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372122 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds -Oz as option and also properly enables support for -Os.
Currently, the existing check for -Os is dead, because the enclosing if
only checks of O1, O2 and O3.
There is still a difference between the -Oz pipeline compared to opt,
but I have not been able to track that down yet.
Reviewers: bogner, sebpop, efriedma
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D67593
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372079 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is needed to implemented the same approach as lld (implemented in r338434)
for how to handling symbols that can be generated by LTO code generator
but not present in the symbol table for linker that uses legacy C APIs.
libLTO is in charge of providing the list of symbols. Linker is in
charge of implementing the eager loading from static libraries using
the list of symbols.
rdar://problem/52853974
Reviewers: tejohnson, bd1976llvm, deadalnix, espindola
Reviewed By: tejohnson
Subscribers: emaste, arichardson, hiraditya, MaskRay, dang, kledzik, mehdi_amini, inglorion, jkorous, dexonsmith, ributzka, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67568
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372021 91177308-0d34-0410-b5e6-96231b3b80d8
GNU objcopy documents that -B is only useful with architecture-less
input (i.e. "binary" or "ihex"). After D67144, -O defaults to -I, and
-B is essentially a NOP.
* If -O is binary/ihex, GNU objcopy ignores -B.
* If -O is elf*, -B provides the e_machine field in GNU objcopy.
So to convert a blob to an ELF, `-I binary -B i386:x86-64 -O elf64-x86-64` has to be specified.
`-I binary -B i386:x86-64 -O elf64-x86-64` creates an ELF with its
e_machine field set to EM_NONE in GNU objcopy, but a regular x86_64 ELF
in elftoolchain elfcopy. Follow the elftoolchain approach (ignoring -B)
to simplify code. Users that expect their command line portable should
specify -B.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D67215
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371914 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes PR42171.
In GNU objcopy, if -O (--output-target) is not specified, the value is
copied from -I (--input-target).
```
objcopy -I binary -B i386:x86-64 a.txt b # b is copied from a.txt
llvm-objcopy -I binary -B i386:x86-64 a.txt b # b is an x86-64 object file
```
This patch changes our behavior to match GNU. With this change, we can
delete code related to -B handling (D67215).
Reviewed By: jakehehrlich
Differential Revision: https://reviews.llvm.org/D67144
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371913 91177308-0d34-0410-b5e6-96231b3b80d8
Most GNU binutils don't append full stops in error messages. This
convention has been adopted by a bunch of LLVM binary utilities. Make
llvm-ar follow the convention as well.
Reviewed By: grimar
Differential Revision: https://reviews.llvm.org/D67558
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371912 91177308-0d34-0410-b5e6-96231b3b80d8
* std::move the error extracted from the parsing creation to avoid asserts
* print a newline after the error message
* create the parser from the metadata
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371895 91177308-0d34-0410-b5e6-96231b3b80d8
This is a continuation of the YAML library error reporting
refactoring/improvement and the idea by itself was mentioned
in the following thread:
https://reviews.llvm.org/D67182?id=218714#inline-603404
This performs a cleanup of all object emitters in the library.
It allows using the custom one provided by the caller.
One of the nice things is that each tool can now print its tool name,
e.g: "yaml2obj: error: <text>"
Also, the code became a bit simpler.
Differential revision: https://reviews.llvm.org/D67445
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371865 91177308-0d34-0410-b5e6-96231b3b80d8
Patch by Justice Adams!
Made llvm-objdump --all-headers output match the order of GNU objdump for compatibility reasons.
Old order of the headers output:
* file header
* section header table
* symbol table
* program header table
* dynamic section
New order of the headers output (GNU compatible):
* file header information
* program header table
* dynamic section
* section header table
* symbol table
(Relevant BugZilla Bug: https://bugs.llvm.org/show_bug.cgi?id=41830)
Differential revision: https://reviews.llvm.org/D67357
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371826 91177308-0d34-0410-b5e6-96231b3b80d8
Fixing a couple of asan-identified bugs
* use of an invalid "Use" iterator after the element was removed
* use of StringRef to Function name after the Function was erased
This reapplies r371567, which was reverted in r371580.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371700 91177308-0d34-0410-b5e6-96231b3b80d8
This modifies the tool somewhat to only create files when about to run
the "interestingness" test, and delete them immediately after - this
means some more files will be created sometimes (when "double checking"
work - which should probably be fixed/avoided anyway).
This now creates temporary files, rather than only unique ones, and also
uses ToolOutputFile (without ever calling "keep") to ensure the files
are deleted as soon as the interestingness test is run.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371696 91177308-0d34-0410-b5e6-96231b3b80d8
llvm::sys::ExecuteAndWait can report errors, so let's make use of that.
Second, while iterating uses of functions to remove, a call can appear
multiple times. Use a SetVector so we don't attempt to erase such a call
twice.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371653 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This commit is the final one for adding tapi support to the llvm-nm implementation.
This commit also has accompanying tests the additions to lib/Object
Reviewers: ributzka, steven_wu
Reviewed By: ributzka
Subscribers: hiraditya, plotfi, dexonsmith, rupprecht, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66160
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371576 91177308-0d34-0410-b5e6-96231b3b80d8
Also fix llvm-reduce to use the specified output file name directly,
without appending '.ll' to the name.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371555 91177308-0d34-0410-b5e6-96231b3b80d8
The bitstream remark serializer landed in r367372.
This adds a bitstream remark parser that parser bitstream remark files
to llvm::remarks::Remark objects through the RemarkParser interface.
A few interesting things to point out:
* There are parsing helpers to parse the different types of blocks
* The main parsing helper allows us to parse remark metadata and open an
external file containing the encoded remarks
* This adds a dependency from the Remarks library to the BitstreamReader
library
* The testing strategy is to create a remark entry through YAML, parse
it, serialize it to bitstream, parse that back and compare the objects.
* There are close to no tests for malformed bitstream remarks, due to
the lack of textual format for the bitstream format.
* This adds a new C API for parsing bitstream remarks:
LLVMRemarkParserCreateBitstream.
* This bumps the REMARKS_API_VERSION to 1.
Differential Revision: https://reviews.llvm.org/D67134
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371429 91177308-0d34-0410-b5e6-96231b3b80d8
Similar to D67254.
`struct Elf*_Shdr` has a field `sh_offset`. Rename SHOffset to SHOff to
avoid confusion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371281 91177308-0d34-0410-b5e6-96231b3b80d8
The llvm-jitlink utility now accepts a '-slab-allocate <size>' option. If given,
llvm-jitlink will use a slab-based memory manager rather than the default
InProcessMemoryManager. Using a slab allocator will allow reliable testing of
future locality based optimizations (e.g. PLT and GOT elimination) in JITLink.
The <size> argument is a number, optionally followed by a units specifier (Kb,
Mb, or Gb). If the units are not given then the number is assumed to be in Kb.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371244 91177308-0d34-0410-b5e6-96231b3b80d8
This is a fix for https://bugs.llvm.org/show_bug.cgi?id=40785.
llvm-readelf does not print the st_value of the symbol when
st_value has any non-visibility bits set.
This patch:
* Aligns "Ndx" row for the default and a new cases.
(it was 1 space character off for the case when "PROTECTED" visibility was printed)
* Prints "[<other>: 0x??]" for symbols which has an additional st_other bits set.
In compare with GNU, this logic is a bit simpler and seems to be more consistent.
For MIPS GNU can print named flags, though can't print a mix of them:
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 NOTYPE GLOBAL DEFAULT [OPTIONAL] UND a1
2: 00000000 0 NOTYPE GLOBAL DEFAULT [MIPS PLT] UND a2
3: 00000000 0 NOTYPE GLOBAL DEFAULT [MIPS PIC] UND a3
4: 00000000 0 NOTYPE GLOBAL DEFAULT [MICROMIPS] UND a4
5: 00000000 0 NOTYPE GLOBAL DEFAULT [MIPS16] UND a5
6: 00000000 0 NOTYPE GLOBAL DEFAULT [<other>: c] UND b1
7: 00000000 0 NOTYPE GLOBAL DEFAULT [<other>: 28] UND b2
On PPC64 it can print a localentry value that is encoded in the high bits of st_other
63: 0000000000000850 208 FUNC GLOBAL DEFAULT [<localentry>: 8] 12
We chose to print the raw st_other field, prefixed with '0x'.
Differential revision: https://reviews.llvm.org/D67094
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371201 91177308-0d34-0410-b5e6-96231b3b80d8
D62179 introduced a regression. llvm-readelf lose the ability to dump the dynamic symbols
when there is .dynamic section with a DT_SYMTAB, but there are no program headers:
https://reviews.llvm.org/D62179#1652778
Below is a program flow before the D62179 change:
1) Find SHT_DYNSYM.
2) Find there is no PT_DYNAMIC => don't try to parse it.
3) Print dynamic symbols using information about them found on step (1).
And after the change it became:
1) Find SHT_DYNSYM.
2) Find there is no PT_DYNAMIC => find SHT_DYNAMIC.
3) Parse dynamic table, but fail to handle the DT_SYMTAB because of the absence of the PT_LOAD. Report the "Virtual address is not in any segment" error.
This patch fixes the issue. For doing this it checks that the value of DT_SYMTAB was
mapped to a segment. If not - it ignores it.
Differential revision: https://reviews.llvm.org/D67078
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@371071 91177308-0d34-0410-b5e6-96231b3b80d8
This ambiguity (struct member name matching struct name) was causing errors on
a few of the MSVC bots. Hopefully this should fix it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@370969 91177308-0d34-0410-b5e6-96231b3b80d8
When using llvm-rtdyld to execute code, -show-times will now show the time
taken to load the object files, apply relocations, and execute the
rtdyld-linked code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@370968 91177308-0d34-0410-b5e6-96231b3b80d8
No longer constantly shows times (even when -show-times=false). When shown,
times are now correctly grouped.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@370951 91177308-0d34-0410-b5e6-96231b3b80d8
