This patch implements --build-id. After the linker creates an output file
in the memory buffer, it computes the FNV1 hash of the resulting file
and set the hash to the .note section as a build-id.
GNU ld and gold have the same feature, but their default choice of the
hash function is different. Their default is SHA1.
We made a deliberate choice to not use a secure hash function for the
sake of performance. Computing a secure hash is slow -- for example,
MD5 throughput is usually 400 MB/s or so. SHA1 is slower than that.
As a result, if you pass --build-id to gold, then the linker becomes about
10% slower than that without the option. We observed a similar degradation
in an experimental implementation of build-id for LLD. On the other hand,
we observed only 1-2% performance degradation with the FNV hash.
Since build-id is not for digital certificate or anything, we think that
a very small probability of collision is acceptable.
We considered using other signals such as using input file timestamps as
inputs to a secure hash function. But such signals would have an issue
with build reproducibility (if you build a binary from the same source
tree using the same toolchain, the build id should become the same.)
GNU linkers accepts --build-id=<style> option where style is one of
"MD5", "SHA1", or an arbitrary hex string. That option is out of scope
of this patch.
http://reviews.llvm.org/D18091
llvm-svn: 263292
It was discussed to make all messages be
lowercase to be consistent with clang.
(also reverts the r263128 which fixed
build bot fail after r263125)
Original commit message:
[ELF] - Consistent spelling for error/warning messages
Previously error and warnings were not consistent in lld.
Some of them started from lowercase letter, others from
uppercase. Also there was one or two which had a dot at the end.
This patch changes all messages to start from uppercase letter if
they were not before.
Differential revision: http://reviews.llvm.org/D18045
llvm-svn: 263240
We can argue about a maximum alignment of a group of symbols,
but for each symbol, there is only one alignment.
So it is a bit weird that each symbol has a "maximum alignment".
llvm-svn: 263151
Previously error and warnings were not consistent in lld.
Some of them started from lowercase letter, others from
uppercase. Also there was one or two which had a dot at the end.
This patch changes all messages to start from uppercase letter if
they were not before.
Differential revision: http://reviews.llvm.org/D18045
llvm-svn: 263125
It was a badly specified hack for when a tls relocation should be
propagated to the dynamic relocation table.
This replaces it with a not as bad hack of saying that a local dynamic
tls relocation is never preempted.
I will try to remove even that second hack in the next patch.
llvm-svn: 262955
The variables corresponding to command line options are named mechanically.
Because the option for the variable is -noinhibit-exec and not -no-inhibit-exec,
it should be name this way.
llvm-svn: 262911
Get rid of few accessors in that class, and replace
them with direct fields access.
Differential revision: http://reviews.llvm.org/D17879
llvm-svn: 262796
Patch changes all relocations types to be uint32_t and also
fixes some dependent inconsistency in callers code.
Differential revision: http://reviews.llvm.org/D17882
llvm-svn: 262793
The rules for when we can relax tls relocations are target independent.
The only things that are target dependent are the relocation values.
llvm-svn: 262748
SymbolBody constructor and friends take isFunc and isTLS boolean arguments.
ELF symbols have already a type so than be easily passed as argument.
If we want to support another type, this scheme is not good enough, that is,
the current code logic would require passing another `bool isObject` around.
Up to two argument, this stretching exercise was a little bit goofy but
still acceptable, but with more types to support, is just too much, IMHO.
Change the code so that the type is passed instead.
Differential Revision: http://reviews.llvm.org/D17871
llvm-svn: 262684
When generating relocatable output SHT_NOBITS sections
were still occupy the file space.
Differential revision: http://reviews.llvm.org/D17857
llvm-svn: 262650
There was a known limitation for -r option:
relocations against local symbols were not supported.
For example rel[a].eh_frame sections contained relocations against sections
and that was not supported for -r before. Patch fixes that.
Differential review: http://reviews.llvm.org/D17813
llvm-svn: 262590
As was suggested in mails, this patch implements edata/etext
symbols in a more direct way.
It iterates through PT_LOADs.
Result seems to be the same and equal to gold output.
Differential revision: http://reviews.llvm.org/D17755
llvm-svn: 262369
__start_/__end_ <section-name> symbols and other specials like:
preinit_array_start/end
init_array_start/end
fini_array_start/end
should not be created by linker when creating relocatable files.
Differential revision: http://reviews.llvm.org/D17774
llvm-svn: 262366
Regarding the comment, it is out of context because it describes
what it does not do there. It got too long because it was originally
two different comments that were simply merged together.
The semantics is described in fixAbsoluteSymbols, so we don't need it.
llvm-svn: 262031
https://docs.oracle.com/cd/E53394_01/html/E54766/u-etext-3c.html
It is said that:
_etext - The address of _etext is the first
location after the last read-only loadable segment.
_edata - The address of _edata is the first
location after the last read-write loadable segment.
_end - If the address of _edata is greater than the address
of _etext, the address of _end is same as the address of _edata.
In real life _end and _edata has different values for that case.
Both gold/bfd set _edata to the end of the last non SHT_NOBITS section.
This patch do the same for consistency.
It should fix the https://llvm.org/bugs/show_bug.cgi?id=26729.
Differential revision: http://reviews.llvm.org/D17601
llvm-svn: 262019
For shared libraries we allow any weak undefined symbol to eventually be
resolved, even if we never see a definition in another .so. This matches
the behavior when handling other undefined symbols in a shared library.
For executables, we require seeing a definition in a .so or resolve it
to zero. This is also similar to how non weak symbols are handled.
llvm-svn: 262017
-r, -relocatable - Generate relocatable output
Currently does not have support for files containing
relocation sections with entries that refer to local
symbols (like rel[a].eh_frame which refer to sections
and not to symbols)
Differential revision: http://reviews.llvm.org/D14382
llvm-svn: 261838
"Discarded" section is a marker for discarded sections, and we do not
use the instance except for checking its identity. In that sense, it
is just another type of a "null" pointer for InputSectionBase. So,
it doesn't have to be a real instance of InputSectionBase class.
In this patch, we no longer instantiate Discarded section but instead
use -1 as a pointer value. This eliminates a global variable which
needed initialization at startup.
llvm-svn: 261761
There is nothing aarch64 specific in here. If a symbol can be preempted,
we need to copy the full relocation to the dynamic linker.
If a symbol cannot be preempted, we can make the dynamic linker life
easier and produce a relative relocation.
This is directly equivalent to R_X86_64_64 to R_x86_64_RELATIVE
conversion.
llvm-svn: 261678
