The _gp_disp symbol designates offset between start of function and 'gp'
pointer into GOT. The following code is a typical MIPS function preamble
used to setup $gp register:
lui $gp, %hi(_gp_disp)
addi $gp, $gp, %lo(_gp_disp)
To calculate R_MIPS_HI16 / R_MIPS_LO16 relocations results we use
the following formulas:
%hi(_gp - P + A)
%lo(_gp - P + A + 4),
where _gp is a value of _gp symbol, A is addend, and P current address.
The R_MIPS_LO16 relocation references _gp_disp symbol is always the second
instruction. That is why we need four byte adjustments. The patch assigns
R_PC type for R_MIPS_LO16 relocation and adjusts its addend by 4. That fix
R_MIPS_LO16 calculation.
For details see p. 4-19 at ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf
Differential Revision: http://reviews.llvm.org/D19115
llvm-svn: 266368
We never need to iterate over the K,V pairs, so we can avoid copying the
key as MapVector does.
This is a small speedup on most benchmarks.
llvm-svn: 266364
The DenseMap doesn't store hash results. This means that when it is
resized it has to recompute them.
This patch is a small hack that wraps the StringRef in a struct that
remembers the hash value. That way we can be sure it is only hashed
once.
llvm-svn: 266357
That was removed in r266304, but leads to warnings by Clang.
Thanks to Rafael Espíndola for pointing on that.
Though I think change was legal from point of C++.
llvm-svn: 266306
They are unnecessary, as the dynamic loader can apply the original relocations
directly. This was also resulting in the creation of copy relocations in PIEs.
Differential Revision: http://reviews.llvm.org/D19089
llvm-svn: 266273
This patch implements the --dynamic-list option, which adds a list of
global symbol that either should not be bounded by default definition
when creating shared libraries, or add in dynamic symbol table in the
case of creating executables.
The patch modifies the ScriptParserBase class to use a list of Token
instead of StringRef, which contains information if the token is a
quoted or unquoted strings. It is used to use a faster search for
exact match symbol name.
The input file follow a similar format of linker script with some
simplifications (it does not have scope or node names). It leads
to a simplified parser define in DynamicList.{cpp,h}.
Different from ld/gold neither glob pattern nor mangled names
(extern 'C++') are currently supported.
llvm-svn: 266227
Previously each archive file was reported no matter were it's member used or not,
like:
lib/libLLVMSupport.a
Now lld prints line for each used internal file, like:
lib/libLLVMSupport.a(lib/Support/CMakeFiles/LLVMSupport.dir/StringSaver.cpp.o)
lib/libLLVMSupport.a(lib/Support/CMakeFiles/LLVMSupport.dir/Host.cpp.o)
lib/libLLVMSupport.a(lib/Support/CMakeFiles/LLVMSupport.dir/ConvertUTF.c.o)
That should be consistent with what gold do.
This fixes PR27243.
Differential revision: http://reviews.llvm.org/D19011
llvm-svn: 266220
This simplifies the code by allowing us to remove the visibility argument
to functions that create synthetic symbols.
The only functional change is that the visibility of the MIPS "_gp" symbol
is now hidden. Because this symbol is defined in every executable or DSO, it
would be difficult to observe a visibility change here.
Differential Revision: http://reviews.llvm.org/D19033
llvm-svn: 266208
We need to ensure that the address of an undefined weak symbol evaluates to
zero. We were getting this right for non-PIC executables (where the symbol
can be evaluated directly) and for DSOs (where we emit a symbolic relocation
for these symbols, as they are preemptible). But we weren't getting it right
for PIEs. Probably the simplest way to ensure that these symbols evaluate
to zero is by not creating a relocation in .got for them.
Differential Revision: http://reviews.llvm.org/D19044
llvm-svn: 266161
With this patch we use the first scan over the relocations to remember
the information we found about them: will them be relaxed, will a plt be
used, etc.
With that the actual relocation application becomes much simpler. That
is particularly true for the interfaces in Target.h.
This unfortunately means that we now do two passes over relocations for
non SHF_ALLOC sections. I think this can be solved by factoring out the
code that scans a single relocation. It can then be used both as a scan
that record info and for a dedicated direct relocation of non SHF_ALLOC
sections.
I also think it is possible to reduce the number of enum values by
representing a target with just an OutputSection and an offset (which
can be from the start or end).
This should unblock adding features like relocation optimizations.
llvm-svn: 266158
The _gp* family of symbols is defined as an offset in .got, and it is
not at all clear what should happen when .got is not defined.
This will allow some simplifications on how these symbols are handled.
llvm-svn: 266063
It is possible to have FDEs with duplicate PCs if ICF was able to merge
functions with FDEs, or if the input files for some reason contained duplicate
FDEs. We previously weren't handling this correctly when producing the
contents of the .eh_frame_hdr section; we were dropping entries and leaving
null entries at the end of the section, which confused consumers of unwind
data, such as the backtrace() function.
Fix the bug by setting the FDE count to the number of FDEs actually emitted
into .eh_frame_hdr, rather than the number of FDEs in .eh_frame.
Differential Revision: http://reviews.llvm.org/D18911
llvm-svn: 265957
It is possible that the same symbol referenced by two kinds of
relocations at the same time. The first type requires say GOT entry
creation, the second type requires dynamic copy relocation. For MIPS
targets they might be R_MIPS_GOT16 and R_MIPS_HI16 relocations. For X86
target they might be R_386_GOT32 and R_386_32 respectively.
Now LLD never creates GOT entry for a symbol if this symbol already has
related copy relocation. This patch solves this problem.
Differential Revision: http://reviews.llvm.org/D18862
llvm-svn: 265910
Previously, Lazy symbols were created for undefined symbols even though
such symbols cannot be resolved by loading object files. This patch
fixes that bug.
llvm-svn: 265847
Now MustBeInDynSym is only true if the symbol really must be in the
dynamic symbol table.
IsUsedInRegularObj is only true if the symbol is used in a .o or -u. Not
a .so or a .bc.
A benefit is that this is now done almost entirilly during symbol
resolution. The only exception is copy relocations because of aliases.
This includes a small fix in that protected symbols in .so don't force
executable symbols to be exported.
This also opens the way for implementing internalize for -shared.
llvm-svn: 265826
The spec says:
If a symbol definition with STV_PROTECTED visibility from a shared
object is taken as resolving a reference from an executable or another
shared object, the SHN_UNDEF symbol table entry created has STV_DEFAULT
visibility.
llvm-svn: 265792
This patch fixes dynamic relocation creation from GOT access in dynamic
objects on aarch64. Current code creates a plt relative one
(R_AARCH64_JUMP_SLOT) instead of a got relative (R_AARCH64_GLOB_DAT).
It leads the programs fails with:
$ cat t.cc
std::string test = "hello...\n";
int main ()
{
printf ("%s\n", test.c_str());
return 0;
}
$ clang++ t.cc -fpic -o t
$ ./t
hello...
Segmentation fault (core dumped)
Due the fact it will try to access the plt instead of the got for
__cxa_atexit registration for the std::string destruction. It will
lead in a bogus function address in atexit.
llvm-svn: 265784
Previously, we supported only one hash function, FNV-1, so
BuildIdSection directly handled hash computation. In this patch,
I made BuildIdSection an abstract class and defined two subclasses,
BuildIdFnv1 and BuildIdMd5.
llvm-svn: 265737
start-lib and end-lib are options to link object files in the same
semantics as archive files. If an object is in start-lib and end-lib,
the object is linked only when the file is needed to resolve
undefined symbols. That means, if an object is in start-lib and end-lib,
it behaves as if it were in an archive file.
In this patch, I introduced a new notion, LazyObjectFile. That is
analogous to Archive file type, but that works for a single object
file instead of for an archive file.
http://reviews.llvm.org/D18814
llvm-svn: 265710
This requires knowing input section offsets in output sections before
scanRelocs. This is generally a good thing and should allow further
simplifications in the creation of dynamic relocations.
llvm-svn: 265673
Stack is not executable by default in LLD-built executables unless
you pass -z execstack option. So --warn-execstack option does not make
sense to us.
llvm-svn: 265619
With the llvm change in r265606 this is the matching needed change to the lld
code now that createBinary() is returning Expected<...> .
llvm-svn: 265607
This patch add a base script tokenizer class to decouple parsing from
linker script handling. The idea is to use this base class on dynamic
list parsing (--dynamic-list option). No functionality added.
llvm-svn: 265600
Similar to r265462, TLS related relocations aren't marked as relative,
meaning that we end up generating R_AARCH64_RELATIVE relocations for
them. This change adds TLS relocations that I've seen on my system. With
this patch applied CloudABI's unit testing binary now passes on aarch64.
Approved by: ruiu
Differential Revision: http://reviews.llvm.org/D18816
llvm-svn: 265575
We have to differentiate undefined symbols from bitcode and undefined
symbols from other sources.
Undefined symbols from bitcode should not inhibit the symbol being
internalized. Undefined symbols from other sources should.
llvm-svn: 265536
When error, this adds the text line of script to the output
and a marks exact incorrect token under it:
line 1: <error text here>
UNKNOWN_TAG {
^
Differential revision: http://reviews.llvm.org/D18699
llvm-svn: 265523
ELF and program header are not part of OutputSections list anymore.
That helps to avoid having and working with functions like dummySectionsNum().
Still keeping them as sections helps to simplify the code.
Differential revision: http://reviews.llvm.org/D18743
llvm-svn: 265522
Summary:
This bug was introduced by http://reviews.llvm.org/rL265059,
where InputSectionBase got Thunks field, which can do memory allocations.
Since InputSectionBase destructors were never called (I count it as another bug),
that caused a memory leak when 2 or more thunks are added to a section.
The fix to is properly call InputSectionBase destructors from ~ObjectFile.
Reviewers: atanasyan, ruiu, rafael
Subscribers: rafael, krasin, pcc
Differential Revision: http://reviews.llvm.org/D18809
llvm-svn: 265497
While trying to get PIE work on CloudABI for x86-64, I noticed that even
though GNU ld would generate functional binaries, LLD would not. It
turns out that we generate relocations for referencing TLS objects
inside of the text segment, which shouldn't happen.
This change extends the isRelRelative() function to list some additional
relocation types that should be treated as relative. This makes my C
library unit testing binary work on x86-64.
Approved by: ruiu
Differential Revision: http://reviews.llvm.org/D18688
Fixes bug: https://llvm.org/bugs/show_bug.cgi?id=27174
llvm-svn: 265462
Where Clang's AArch64 backend seems to differ from the X86 backend is
that it tends to use the GOT more aggressively.
After getting CloudABI PIEs working on x86-64, I noticed that accessing
global variables would still crash on aarch64. Tracing it down, it turns
out that the GOT was filled with entries assuming the base address was
zero.
It turns out that we skip generating relocations for GOT entries in case
the relocation pointing towards the GOT is relative. Whether the thing
pointing to the GOT is absolute or relative shouldn't make any
difference; the GOT entry itself should contain the absolute address,
thus needs a relocation regardless.
Approved by: rafael
Differential Revision: http://reviews.llvm.org/D18739
llvm-svn: 265453
Make sure to copy the MustBeInDynSym field when replacing shared symbols with
bitcode symbols, and when replacing bitcode symbols with regular symbols
in addCombinedLtoObject. Fixes interposition of DSO symbols with bitcode
symbols in the main executable.
Differential Revision: http://reviews.llvm.org/D18780
llvm-svn: 265371
For each copy relocation that we create, look through the DSO's symbol table
for aliases and create a dynamic symbol for each one. This causes the copy
relocation to correctly interpose any aliases.
Copy relocations are relatively uncommon (on my machine, 56% of binaries in
/usr/bin have no copy relocations probably due to being PIEs, 97% of them
have <10, and the binary with the largest number of them has 97) so it's
probably fine to do this in a relatively inefficient way.
Differential Revision: http://reviews.llvm.org/D18731
llvm-svn: 265354
This test didn't actually test the functionality. The new test
verifies that "-verify" is passed if and only if -disable-verify
is not given.
llvm-svn: 265316
Note, this is https://llvm.org/bugs/show_bug.cgi?id=27187.
The problem here was that just converting an error to a bool doesn't
always set the checked bit. We only set that bit if the Error didn't
actually contain an error. Otherwise we'd end potentially up silently
dropping it.
Instead just use the consumeError method which is designed to allow us
to drop an error.
llvm-svn: 265311
The only way to get an object file with symbols marked by the STO_MIPS_PIC
flag is to link PIC and non-PIC object files and generate a relocatable
output using '-r' command line option. Now LLD is able to generate a relocatable
output but does not mark PIC symbols by the STO_MIPS_PIC flag. So I have
to use binary input mips-sto-pic.o generated by GNU BFD linker.
llvm-svn: 265310
Our symbol representation was redundant, and some times would get out of
sync. It had an Elf_Sym, but some fields were copied to SymbolBody.
Different parts of the code were checking the bits in SymbolBody and
others were checking Elf_Sym.
There are two general approaches to fix this:
* Copy the required information and don't store and Elf_Sym.
* Don't copy the information and always use the Elf_Smy.
The second way sounds tempting, but has a big problem: we would have to
template SymbolBody. I started doing it, but it requires templeting
*everything* and creates a bit chicken and egg problem at the driver
where we have to find ELFT before we can create an ArchiveFile for
example.
As much as possible I compared the test differences with what gold and
bfd produce to make sure they are still valid. In most cases we are just
adding hidden visibility to a local symbol, which is harmless.
In most tests this is a small speedup. The only slowdown was scylla
(1.006X). The largest speedup was clang with no --build-id, -O3 or
--gc-sections (i.e.: focus on the relocations): 1.019X.
llvm-svn: 265293
So, there are some cases when the IR Linker produces a broken
module (which doesn't pass the verifier) and we end up asserting
inside the verifier. I think it's always a bug producing a module
which does not pass the verifier but there are some cases in which
people can live with the broken module (e.g. if only DebugInfo
metadata are broken). The gold plugin has something similar.
This commit is motivated by a situation I found in the
wild. It seems that somebody else discovered it independently
and reported in PR24923.
llvm-svn: 265258
We already got this right, but it never hurts adding another
test, in case we'll change the handling in the future, to ensure
we don't break it.
llvm-svn: 265256
Currently we create a file called .lto.bc. In UNIX,
ls(1) by default doesn't show up files starting with
a dot, as they're (only by convention) hidden.
This makes the output of -save-temps a little bit
hard to find. Use "a.out.lto.bc" instead if the
output file is not specified.
While here, change an existing -save-temps test to
exercise this more interesting behaviour.
llvm-svn: 265254
GNU ld seems to write a PT_INTERP header into executables containing a
default (read: bogus) value if --dynamic-linker flag is not provided.
LLD is different in the sense that it omits it unless --dynamic-linker
is provided, which seems fair.
Binutils 2.26 added a new flag, --no-dynamic-linker, that can be used to
generate binaries without PT_INTERP. Let's go ahead and also add this
flag to LLD, so that we can invoke the linker in a portable way.
Reviewed by: ruiu
Differential Revision: http://reviews.llvm.org/D18723
llvm-svn: 265246
DefinedElf was a superclass of DefinedRegular and SharedSymbol classes
and represented the notion of defined symbols created for ELF symbols.
It turned out that we didn't use that class often. We had only two
occurrences of dyn_cast'ing to DefinedElf, and both were easily
rewritten without it.
The class was also a bit confusing. The concept of "created for ELF
symbol" is orthogonal to defined/undefined types. However, we had
two distinct classes, DefinedElf and UndefinedElf.
This patch simply removes the class. Now the class hierarchy is one
level shallower.
llvm-svn: 265234
If a symbol is defined in an archive, when we replace its body
the isUsedInRegularObj wasn't set correctly. Internalize makes
its decision based on that bit so we ended up internalizing
symbols that we shouldn't (because they're referenced).
This should fix. Thanks to Peter and Rafael for discussion
and help diagnosing the issue!
Found during LTO of unittests.
llvm-svn: 265208
c:\b\slave\sanitizer-windows\llvm\tools\lld\elf\Config.h(94) : error C2797: 'lld:🧝:Configuration::MLlvm': list initialization inside member initializer list or non-static data member initializer is not implemented
llvm-svn: 265207
Extracts code for initializing dummies sections
to avoid possible duplication in following patches.
Differential review: http://reviews.llvm.org/D18691
llvm-svn: 265159
Some functions in Writer reports error using HasError, and some reports
their return values. This patch makes them to consistently use HasError.
llvm-svn: 265156
fixAbsoluteSymbols fixes linker-created symbol addresses. Since we don't
create such symbols for relocatable output, we don't need to call this
function.
llvm-svn: 265154
assignAddressesRelocatable function did not set addresses to sections
despite its name. What it actually did is to set file offsets to sections.
assignAddresses function assigned addresses and file offsets to sections.
So there was a confusion what they were doing, and they had duplicate code.
This patch separates file offset assignments from address assignments.
A new function, assignFileOffsets assign file offsets. assignAddresses
do not care about file offsets anymore.
llvm-svn: 265151
The extra fix is to note that it still requires copy relocations.
Original message:
Change how we handle R_MIPS_LO16.
Mips aligns PT_LOAD to 16 bits (0x10000). That means that the lower 16
bits are always the same, so we can, effectively, say that the
relocation is relative.
P.S.: Suggestions for a better name for the predicate are welcome :-)
llvm-svn: 265150
That is consistent with other symbols: _edata, _etext
and can help to avoid duplicate code.
Differential revision: http://reviews.llvm.org/D18655
llvm-svn: 265129
This fixes bootstrap of llvm-tblgen (with LTO) and PR27150.
Slightly longer explanation follows.
Emission of .init_array instead of .ctors is supported only on a
subset of the Target LLVM supports. Codegen needs to be conservative
and always emit .ctors unless instructed otherwise (based on target).
If the dynamic linker sees .init_array it completely ignores
what's inside .ctors and therefore some constructors are not called
(and this causes llvm-tblgen to crash on startup).
Teach LLD/LTO about the Codegen options so we end up always emitting
.init_array and avoid this issue.
In future, we might end up supporting mix of .ctors and .init_array
in different input files if this shows up as a real-world use case.
The way gold handles this case is mapping .ctors from input into
.init_array in output. There's also another caveat because
as far as I understand .ctors run in reverse order so when we do
the copy/mapping we need to reverse copy in the output if there's
more than one ctor. That's why I'd rather avoid this complicate logic
unless there's a real need.
An analogous reasoning holds for .dtors/.fini_array.
llvm-svn: 265085
Some targets might require creation of thunks. For example, MIPS targets
require stubs to call PIC code from non-PIC one. The patch implements
infrastructure for thunk code creation and provides support for MIPS
LA25 stubs. Any MIPS PIC code function is invoked with its address
in register $t9. So if we have a branch instruction from non-PIC code
to the PIC one we cannot make the jump directly and need to create a small
stub to save the target function address.
See page 3-38 ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf
- In relocation scanning phase we ask target about thunk creation necessity
by calling `TagetInfo::needsThunk` method. The `InputSection` class
maintains list of Symbols requires thunk creation.
- Reassigning offsets performed for each input sections after relocation
scanning complete because position of each section might change due
thunk creation.
- The patch introduces new dedicated value for DefinedSynthetic symbols
DefinedSynthetic::SectionEnd. Synthetic symbol with that value always
points to the end of the corresponding output section. That allows to
escape updating synthetic symbols if output sections sizes changes after
relocation scanning due thunk creation.
- In the `InputSection::writeTo` method we write thunks after corresponding
input section. Each thunk is written by calling `TargetInfo::writeThunk` method.
- The patch supports the only type of thunk code for each target. For now,
it is enough.
Differential Revision: http://reviews.llvm.org/D17934
llvm-svn: 265059
We have to check the final value that is written.
I don't think this has any real word implications (unless something
supports unaligned instructions), but unblocks simplifying the handling
of PC relative relocations.
llvm-svn: 265009
This reverts commit r264945.
The commit only removed an unreachable in a method with a covered switch, but
GCC is likely to warn on this, and the coding standards recommend just leaving
in the unreachable.
llvm-svn: 264983
make_dynamic_error_code was used to create a std::error_code with
a std::string message. Now that we are migrating to llvm::Error,
there are no calls to these make_dynamic_error_code methods.
There is one single call to make_dynamic_error_code remaining, the one
inside GenericError::convertToErrorCode(). That method is only called
from File::doParse() which should be a temporary situation. We need
to work out how to deal with File::parse() caching the error result from
doParse(). Caching errors isn't supported in the new scheme, and probably
isn't needed here, but we need to work that out.
Once thats done, dynamic error and all utilities around it can be deleted.
llvm-svn: 264982
These methods weren't really throwing errors. The only error used
was that a file could not be found, which isn't really an error at all
as we are searching paths and libraries for a file. All of the callers
also ignored errors and just used the returned path if one was available.
Changing to return Optional<StringRef> as that actually reflects what
we are trying to do here: optionally find a given path.
llvm-svn: 264979
These methods were responsible for some of the few remaining calls
to llvm::errorCodeToError. Converting them makes us have more Error's
in the api and fewer error_code's.
llvm-svn: 264974
If we make R_MIPS_LO16 a relative relocation, linker:
- never creates R_MIPS_COPY relocation for it
- attempts to create R_MIPS_REL32 dynamic relocation if R_MIPS_LO16's
target is a preemptible symbol
Differential Revision: http://reviews.llvm.org/D18607
llvm-svn: 264956
Pretty mechanical change here. Just replacing all the std::error_code() with
llvm::Error() and make_dynamic_error_code with make_error<GenericError>
llvm-svn: 264917
Windows seems to complain that the file cannot be removed because
it is still in use. We don't have to remove the file but instead
just overwrite it, so do that.
llvm-svn: 264915
Adds a GenericError class to lld/Core which can carry a string. This is
analygous to the dynamic_error we currently use in lld/Core.
Use this GenericError instead of make_dynamic_error_code. Also, provide
an implemention of GenericError::convertToErrorCode which for now converts
it in to the dynamic_error_code we used to have. This will go away once
all the APIs are converted.
llvm-svn: 264910
This patch add a TLS relax optimization test when transforming
Initial-Exec to Local-Exec for local symbols (which can not be preempted).
llvm-svn: 264903
gold and bfd do not include the undefined locals in symtab.
We have no reasons to support that either.
That fixes PR27016
Differential revision: http://reviews.llvm.org/D18554
llvm-svn: 264843
The original comments were separated by new code that is irrelevant to
the comment. This patch moves the comment to the right place and update it.
llvm-svn: 264816
This simplifies a few things
* Read the value as early as possible, instead of passing a pointer to
the location.
* Print the warning for missing pair close to where we find out it is
missing.
* Don't pass the value to relocateOne.
llvm-svn: 264802
Mips aligns PT_LOAD to 16 bits (0x10000). That means that the lower 16
bits are always the same, so we can, effectively, say that the
relocation is relative.
llvm-svn: 264761
Local symbol which requires GOT entry initialized by "page" address.
This address is high 16 bits of sum of the symbol value and the relocation
addend. In the relocation scanning phase final values of symbols are unknown
so to reduce number of allocated GOT entries do the following trick. Save
all output sections referenced by GOT relocations during the relocation
scanning phase. Then later in the `GotSection::finalize` method calculate
number of "pages" required to cover all saved output sections and allocate
appropriate number of GOT entries. We assume the worst case - each 64kb
page of the output section has at least one GOT relocation against it.
Differential Revision: http://reviews.llvm.org/D18349
llvm-svn: 264730
When R_X86_64_PC32/R_X86_64_32 relocations are
used against preemptible symbol and output is position independent,
error should be generated.
Differential revision: http://reviews.llvm.org/D18190
llvm-svn: 264707
Some optimizations, e.g. SimplifyLibCalls, can replace functions with
others as part of the lowering, e.g. printf => puts.
The new symbols don't have the isUsedInRegularObj flag set so they
don't get included in the final symbol table (and dynamic symbol
table), and the dynamic linker gets confused. Include them as a fix.
Differential Revision: http://reviews.llvm.org/D18357
llvm-svn: 264688
searchArchivesToOverrideTentativeDefinitions and
searchSharedLibrariesToOverrideTentativeDefinitions are always false.
For the dead flags, we have a fairly large amount of code which is
never be executed.
http://reviews.llvm.org/D17791
llvm-svn: 264653
IPO doesn't work very well across symbols referenced
by others TUs. The linker here tries to evaluate
which symbols are safe to internalize and switches
their linkage.
Differential Revision: http://reviews.llvm.org/D18415
llvm-svn: 264585
This flag disables link.exe's crash handler so that normal windows error
reporting and crash dumping occurs. For now it is reasonable for LLD to
ignore the flag.
Chromium is currently using this flag to collect minidumps of link.exe
crashing, and it breaks the LLD build.
llvm-svn: 264439
This patch simplifies the isRelRelative for AArch64 and add the missing
ones for bootstrap and test-suite. It also adds more testing for
shared object creation.
llvm-svn: 264322
The stack-size.yaml test had an empty atom content array. This is
legal, but asking a BumpPtrAllocator for 0 sized data may not be
legal. Instead just avoid requesting any data when we can just return
an empty ArrayRef instead.
llvm-svn: 264234
Its possible for file to have no entry atom which means that there
is no atom to check for being a thumb function. Instead just skip
the thumb check and set the entry address to 0, which matches the
current behaviour of getting a default initialised int from a map.
llvm-svn: 264233
On a 32-bit output, we may write LC_MAIN (which contains a uint64_t) to
an unaligned address. This changes it to use a memcpy instead which is UB safe.
llvm-svn: 264232
We were casting a potentially unaligned pointer to uint32_t and
dereferencing. As the pointer ultimately comes from the object file,
there's no way to guarantee alignment, so use the little32_t read instead.
Also, little32_t knows about endianness, so in theory this may have broken on
big endian machines.
llvm-svn: 264231
The .o path always makes sure to store a power of 2 value in the
Section alignment. However, the YAML code didn't verify this.
Added verification and updated all the tests which had a 3 but meant
to have 2^3.
llvm-svn: 264228
The size of a section can be zero, even when it contains atoms, so
long as all of the atoms are also size 0. In this case we were
allocating space for a 0 sized buffer.
Changed this to only allocate when we need the space, but also cleaned
up all the code to use MutableArrayRef instead of uint8_t* so its much much
safer as we get bounds checking on all of our section creation logic.
llvm-svn: 264204
On a 32-bit output, we may write LC_SOURCE_VERSION (which contains a uint64_t) to
an unaligned address. This changes it to use a memcpy instead which is UB safe.
llvm-svn: 264202
We were already copying this data to a temporary for endian swaps. Now
we just always copy it, but still only do the endian swaps when needed.
llvm-svn: 264172
Turns out that checking only x86 for empty atoms to fix UBSan then
requires the same code in the other targets too. Better to just
check this in the main run loop instead of in each target.
Should be NFC, other than fixing UBSan failures.
llvm-svn: 264116
This was caught by the UBSan bot. When the atom has no size, we would
issue a memcpy with size0 and a nullptr for the source.
Also, this code should never have references inside an empty atom so
add an assert for that while we're here.
llvm-svn: 264115
Ensure we keep the symbol we need to before it reaches
the Writer (and hit an assertion), changing its linkage
from linkonce_odr to weak. For a more detailed description
of the problem, see PR19901 where a similar problem was
fixed for the gold plugin. Thanks to Rafael for providing
a testcase.
llvm-svn: 264111
If the LHS of 'a = b' already had an atom in it then we wouldn't
call the destructor. This happens when we use something like
std::remove_if which is done in the CompactUnwindPass. Should fix
the leaks on the mach-o/unwind-info-simple-x86_64.yaml test case.
Lang and I are going to take a look at removing OwningAtomPtr in
favour of a std::unique_ptr but just trying to get the bots green
so we have a good baseline first.
llvm-svn: 264097
Simon Atanasyan