This allows syntax like:
$ llvm-ar -c -r -u file.a file.o
This is in addition to the other formats that are already supported:
$ llvm-ar cru file.a file.o
$ llvm-ar -cru file.a file.o
Patch by Tom Anderson!
Differential Revision: https://reviews.llvm.org/D44452
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@328716 91177308-0d34-0410-b5e6-96231b3b80d8
Neither the linker nor the runtime need this information
anymore. We were originally using this to model BSS size
but the plan is now to use the segment metadata to allow
for BSS segments.
Differential Revision: https://reviews.llvm.org/D41366
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326267 91177308-0d34-0410-b5e6-96231b3b80d8
This is combination of two patches by Nicholas Wilson:
1. https://reviews.llvm.org/D41954
2. https://reviews.llvm.org/D42495
Along with a few local modifications:
- One change I made was to add the UNDEFINED bit to the binary format
to avoid the extra byte used when writing data symbols. Although this
bit is redundant for other symbols types (i.e. undefined can be
implied if a function or global is a wasm import)
- I prefer to be explicit and consistent and not have derived flags.
- Some field renaming.
- Some reverting of unrelated minor changes.
- No test output differences.
Differential Revision: https://reviews.llvm.org/D43147
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325860 91177308-0d34-0410-b5e6-96231b3b80d8
The ELF specification says that all ELF data structures are aligned to
their natural alignments both in memory and file. That means when we
access mmap'ed ELF files, we could assume that all data structures are
aligned properly.
However, in reality, we assume that the data structures are aligned only
to two bytes because .a files only guarantee that their member files are
aligned to two bytes in archive files. So the data access is already
unaligned.
This patch relaxes the alignment requirement even more, so that we
accept unaligned access to all ELF data structures.
This patch in particular makes lld bug-compatible with icc. Intel C
compiler doesn't seem to care about data alignment and generates unaligned
relocation sections (https://bugs.llvm.org/show_bug.cgi?id=35854).
I also saw another instance of compatibility issues with our internal tool
which creates unaligned section headers.
Because GNU linkers are not picky about alignment, looks like it is
not uncommon that ELF-generating tools create unaligned files.
There is a performance penalty with this patch on host machines on which
unaligned access is expensive. x86 and AArch64 are fine. ARMv6 is a
problem, but I don't think using ARMv6 machines as hosts is common, so I
believe it's not a real problem.
Differential Revision: https://reviews.llvm.org/D41978
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@322407 91177308-0d34-0410-b5e6-96231b3b80d8
Even with the sparse file optimizations the SYM64 test can still be painfully
slow. This unnecessarily slows down devs. It's critical that we test that the
switch to the SYM64 format occurs at 4GB but there isn't any better of a way to
fake the size of the file than sparse files. This change introduces a flag that
allows the cutoff to be arbitrarily set to whatever power of two is desired.
The flag is hidden as it really isn't meant to be used outside this one test.
This is unfortunate but appears necessary, at least until the average hard
drive is much faster.
The changes to the test require some explanation. Prior to this change we knew
that the SYM64 format was being used because the file was simply too large to
have validly handled this case if the SYM64 format were not used. To ensure
that the SYM64 format is still being used I am grepping the file for "SYM64".
Without changing the filename however this would be pointless because "SYM64"
would occur in the file either way. So the filename of the test is also changed
in order to avoid this issue.
Differential Revision: https://reviews.llvm.org/D40632
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319507 91177308-0d34-0410-b5e6-96231b3b80d8
While the ArrayRef can technically have unaligned data, it would be
extremely surprising if iterating over it caused undefined behavior
when a reference to the underlying type was bound.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319392 91177308-0d34-0410-b5e6-96231b3b80d8
Tests were failing because some bots were running out of address
space and memory. Additionally the test was very slow. These issues
were solved by changing the test to take advantage of sparse filse and
restricting the test to run only on 64-bit systems.
This should fix https://bugs.llvm.org//show_bug.cgi?id=34189
This change makes it so that if writing a K_GNU style archive, you need
to output a > 32-bit offset it should output in K_GNU64 style instead.
Differential Revision: https://reviews.llvm.org/D36812
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317352 91177308-0d34-0410-b5e6-96231b3b80d8
static __global int Var = 0;
__global int* Ptr[] = {&Var};
...
In this case Var is a non premptable symbol and so its address can be used as the value of Ptr, with a base relative relocation that will add the delta between the ELF address and the actual load address. Such relocations do not require a symbol.
Differential Revision: https://reviews.llvm.org/D38909
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315935 91177308-0d34-0410-b5e6-96231b3b80d8
getRelocationAddend should never be called on non SHT_RELA sections,
but changing that requires changing RelocVisitor.h.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315473 91177308-0d34-0410-b5e6-96231b3b80d8
With this all clients have to use the new create method which returns
an Expected.
Fixes a crash on invalid input.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315376 91177308-0d34-0410-b5e6-96231b3b80d8
This forces every user to use the new create method that returns an
Expected. This in turn propagates better error messages.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315371 91177308-0d34-0410-b5e6-96231b3b80d8
Ensure the program_headers call will fail correctly if the program
headers are larger than the underlying buffer.
Patch by Parker Thompson!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315012 91177308-0d34-0410-b5e6-96231b3b80d8
As discussed on llvm-dev in
http://lists.llvm.org/pipermail/llvm-dev/2017-September/117301.html
this changes the command line interface of llvm-dwarfdump to match the
one used by the dwarfdump utility shipping on macOS. In addition to
being shorter to type this format also has the advantage of allowing
more than one section to be specified at the same time.
In a nutshell, with this change
$ llvm-dwarfdump --debug-dump=info
$ llvm-dwarfdump --debug-dump=apple-objc
becomes
$ dwarfdump --debug-info --apple-objc
Differential Revision: https://reviews.llvm.org/D37714
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@312970 91177308-0d34-0410-b5e6-96231b3b80d8
Without this we would have multiple relocations pointing to symbols
with the same name: the empty string. There was no way for yaml2obj to
be able to handle that.
A more general solution would be to unique symbol names in a similar
way to how we unique section names. In practice I think this covers
all common cases and is a bit more user friendly than using names like
sym1, sym2, sym3, etc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@312603 91177308-0d34-0410-b5e6-96231b3b80d8
Without this patch passing a .o file with multiple sections with the
same name to obj2yaml produces a yaml file that yaml2obj cannot
handle. This is pr34162.
The problem is that when specifying, for example, the section of a
symbol, we get only
Section: foo
and don't know which of the sections whose name is foo we have to use.
One alternative would be to use section numbers. This would work, but
the output from obj2yaml would be very inconvenient to edit as
deleting a section would invalidate all indexes.
Another alternative would be to invent a unique section id that would
exist only on yaml. This would work, but seems a bit heavy handed. We
could make the id optional and default it to the section name.
Since in the last alternative the id is basically what this patch uses
as a name, it can be implemented as a followup patch if needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@312585 91177308-0d34-0410-b5e6-96231b3b80d8
The %T lit expansion expands to a common directory shared between all the tests in the same directory, which is unexpected and unintuitive, and more importantly, it's been a source of subtle race conditions and flaky tests. In https://reviews.llvm.org/D35396, it was agreed that it would be best to simply ban %T and only keep %t, which is unique to each test. When a test needs a temporary directory, it can just create one using mkdir %t.
This patch removes %T in llvm.
Differential Revision: https://reviews.llvm.org/D36495
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@310953 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
ELF linkers generate __start_<secname> and __stop_<secname> symbols
when there is a value in a section <secname> where the name is a valid
C identifier. If dead stripping determines that the values declared
in section <secname> are dead, and we then internalize (and delete)
such a symbol, programs that reference the corresponding start and end
section symbols will get undefined reference linking errors.
To fix this, add the section name to the IRSymtab entry when a symbol is
defined in a specific section. Then use this in the gold-plugin to mark
the symbol as external and visible from outside the summary when the
section name is a valid C identifier.
Reviewers: pcc
Subscribers: mehdi_amini, inglorion, eraman, llvm-commits
Differential Revision: https://reviews.llvm.org/D35639
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@309009 91177308-0d34-0410-b5e6-96231b3b80d8
