lldb prepends the thread name to log entries, and the existing thread
name for the FreeBSD ProcessMonitor thread was longer than the kernel's
supported thread name length, and so was truncated. This made logs hard
to read, as the truncated thread name ran into the log message. Shorten
"lldb.process.freebsd.operation" to just "freebsd.op" so that logs are
more readable.
(Upstreaming to lldb still to be done).
This is a backport of LLVM commit 8331f61a51a7a0a1efbf5ed398e181593023d151,
llvm-svn: 353981:
ELF: Allow GOT relocs pointing to non-preemptable ifunc to resolve to an
IRELATIVE where possible.
This is needed in order to make ifuncs work correctly on PPC64.
It fixes an issue with lld, in which it would skip emitting necessary IRELATIVE
relocations. Without this change, indirect calls to ifuncs would result in a
segmentation fault, in static binaries or when defined in the main binary
(outside shared libraries).
This change also reverts the local
"Preserve relocations against ifuncs when -zifunc-noplt" commit and
replaces it by its upstream version, as part of the merge.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D21102
8.0.1 final release r366581. The only functional change is a fix for a
mismerge of upstream r360816, which properly restores the r2 register
when unwinding on PowerPC64 (See https://reviews.freebsd.org/D20337).
Relnotes: yes
PR: 236062
MFC after: 3 days
X-MFC-With: r349004
[ELF] Handle non-glob patterns before glob patterns in version
scripts & fix a corner case of --dynamic-list
This fixes PR38549, which is silently accepted by ld.bfd.
This seems correct because it makes sense to let non-glob patterns
take precedence over glob patterns.
lld issues an error because
`assignWildcardVersion(ver, VER_NDX_LOCAL);` is processed before
`assignExactVersion(ver, v.id, v.name);`.
Move all assignWildcardVersion() calls after assignExactVersion()
calls to fix this.
Also, move handleDynamicList() to the bottom. computeBinding() called
by includeInDynsym() has this cryptic rule:
if (versionId == VER_NDX_LOCAL && isDefined() && !isPreemptible)
return STB_LOCAL;
Before the change:
* foo's version is set to VER_NDX_LOCAL due to `local: *`
* handleDynamicList() is called
- foo.computeBinding() is STB_LOCAL
- foo.includeInDynsym() is false
- foo.isPreemptible is not set (wrong)
* foo's version is set to V1
After the change:
* foo's version is set to VER_NDX_LOCAL due to `local: *`
* foo's version is set to V1
* handleDynamicList() is called
- foo.computeBinding() is STB_GLOBAL
- foo.includeInDynsym() is true
- foo.isPreemptible is set (correct)
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D64550
This makes it longer necessary to patch the version scripts for the
samba ports, to avoid "duplicate symbol 'pdb_search_init' in version
script" errors.
PR: 230602
MFC after: 3 days
3.4.1, which is still in the stable/10 branch.
It looks like clang 3.4.1 implements static_asserts by instantiating a
temporary static object, and if those are in an anonymous union, it
results in "error: anonymous union can only contain non-static data
members".
To work around this implementation limitation, move the static_asserts
in question out of the anonymous unions.
This should make building the latest stable/11 from stable/10 possible
again.
Reported by: Mike Tancsa <mike@sentex.net>
MFC after: 3 days
libunwind and openmp to the upstream release_80 branch r364487
(effectively, 8.0.1 rc3). The 8.0.1 release will most likely
have no further changes.
MFC after: 1 week
X-MFC-With: r349004
Summary:
Toolchain follow-up to r349350. LLVM patches will be submitted upstream for
9.0 as well.
The bsd.cpu.mk change is required because GNU ld assumes BSS-PLT if it
cannot determine for certain that it needs Secure-PLT, and some binaries do
not compile in such a way to make it know to use Secure-PLT.
Reviewed By: nwhitehorn, bdragon, pfg
Differential Revision: https://reviews.freebsd.org/D20598
libunwind and openmp to the upstream release_80 branch r363030
(effectively, 8.0.1 rc2). The 8.0.1 release should follow this within a
week or so.
MFC after: 2 weeks
[objc-gnustep] Use .init_array not .ctors when requested.
This doesn't make a difference most of the time but FreeBSD/ARM
doesn't run anything in the .ctors array.
This should help with updating the libobjc2 port for armv7.
Requested by: theraven
Upstream PR: https://github.com/gnustep/libobjc2/issues/83
MFC after: 3 days
[ELF] Support --{,no-}allow-shlib-undefined
Summary:
In ld.bfd/gold, --no-allow-shlib-undefined is the default when
linking an executable. This patch implements a check to error on
undefined symbols in a shared object, if all of its DT_NEEDED entries
are seen.
Our approach resembles the one used in gold, achieves a good balance
to be useful but not too smart (ld.bfd traces all DSOs and emulates
the behavior of a dynamic linker to catch more cases).
The error is issued based on the symbol table, different from
undefined reference errors issued for relocations. It is most
effective when there are DSOs that were not linked with -z defs (e.g.
when static sanitizers runtime is used).
gold has a comment that some system libraries on GNU/Linux may have
spurious undefined references and thus system libraries should be
excluded (https://sourceware.org/bugzilla/show_bug.cgi?id=6811). The
story may have changed now but we make --allow-shlib-undefined the
default for now. Its interaction with -shared can be discussed in the
future.
Reviewers: ruiu, grimar, pcc, espindola
Reviewed By: ruiu
Subscribers: joerg, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D57385
Pull in r352943 from upstream lld trunk (by Fangrui Song):
[ELF] Default to --no-allow-shlib-undefined for executables
Summary:
This follows the ld.bfd/gold behavior.
The error check is useful as it captures a common type of ld.so
undefined symbol errors as link-time errors:
// a.cc => a.so (not linked with -z defs)
void f(); // f is undefined
void g() { f(); }
// b.cc => executable with a DT_NEEDED entry on a.so
void g();
int main() { g(); }
// ld.so errors when g() is executed (lazy binding) or when the program is started (-z now)
// symbol lookup error: ... undefined symbol: f
Reviewers: ruiu, grimar, pcc, espindola
Reviewed By: ruiu
Subscribers: llvm-commits, emaste, arichardson
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57569
Together, these add support for --no-allow-shlib-undefined, and make it
the default for executables, so they will fail to link if any symbols
from needed shared libraries are undefined.
Reported by: jbeich
PR: 236062, 236141
MFC after: 1 month
X-MFC-With: r344779
Fix inline assembler constraint validation
The current constraint logic is both too lax and too strict. It fails
for input outside the [INT_MIN..INT_MAX] range, but it also
implicitly accepts 0 as value when it should not. Adjust logic to
handle both correctly.
Differential Revision: https://reviews.llvm.org/D58649
Pull in r355491 from upstream clang trunk (by Hans Wennborg):
Inline asm constraints: allow ICE-like pointers for the "n"
constraint (PR40890)
Apparently GCC allows this, and there's code relying on it (see bug).
The idea is to allow expression that would have been allowed if they
were cast to int. So I based the code on how such a cast would be
done (the CK_PointerToIntegral case in
IntExprEvaluator::VisitCastExpr()).
Differential Revision: https://reviews.llvm.org/D58821
These should fix assertions and errors when using the inline assembly
"n" constraint in certain ways.
In case of devel/valgrind, a pointer was used as the input for the
constraint, which lead to "Assertion failed: (isInt() && "Invalid
accessor"), function getInt".
In case of math/secp256k1, a very large integer value was used as input
for the constraint, which lead to "error: value '4624529908474429119'
out of range for constraint 'n'".
PR: 236216, 236194
MFC after: 1 month
X-MFC-With: r344779
not occur with gcc 7 or later). This should prevent the following error
from breaking the head-amd64-gcc CI builds:
In file included from /workspace/src/contrib/llvm/tools/lldb/source/API/SBMemoryRegionInfo.cpp:14:0:
/workspace/src/contrib/llvm/tools/lldb/include/lldb/Target/MemoryRegionInfo.h:128:54: error: 'template<class _InputIterator> lldb_private::MemoryRegionInfos::MemoryRegionInfos(_InputIterator, _InputIterator, const allocator_type&)' inherited from 'std::__1::vector<lldb_private::MemoryRegionInfo>'
using std::vector<lldb_private::MemoryRegionInfo>::vector;
^~~~~~
/workspace/src/contrib/llvm/tools/lldb/include/lldb/Target/MemoryRegionInfo.h:128:54: error: conflicts with version inherited from 'std::__1::vector<lldb_private::MemoryRegionInfo>'
Reported by: CI
Recommit r353293 "[LLD][ELF] - Set DF_STATIC_TLS flag for i386 target."
With the following changes:
1) Compilation fix:
std::atomic<bool> HasStaticTlsModel = false; ->
std::atomic<bool> HasStaticTlsModel{false};
2) Adjusted the comment in code.
Initial commit message:
DF_STATIC_TLS flag indicates that the shared object or executable
contains code using a static thread-local storage scheme.
Patch checks if IE/LE relocations were used to check if the code uses
a static model. If so it sets the DF_STATIC_TLS flag.
Differential revision: https://reviews.llvm.org/D57749
Pull in r353378 from upstream lld trunk (by George Rimar):
[LLD][ELF] - Set DF_STATIC_TLS flag for X64 target
This is the same as D57749, but for x64 target.
"ELF Handling For Thread-Local Storage" p41 says
(https://www.akkadia.org/drepper/tls.pdf):
R_X86_64_GOTTPOFF relocation is used for IE TLS models.
Hence if linker sees this relocation we should add DF_STATIC_TLS flag.
Differential revision: https://reviews.llvm.org/D57821
This adds support to lld for the DF_STATIC_TLS flag in shared objects,
which signals to the dynamic linker that the shared object requires
static thread local storage.
See also: https://reviews.freebsd.org/D19072
MFC after: 1 week
Refactoring. NFC.
Pull in r352435 from upstream lld trunk (by Rui Ueyama):
Attempt to fix build failure with GCC 5.4.
Pull in r352482 from upstream lld trunk (by George Rimar):
[ELF] - Remove dead `readBfdName` declaration. NFC.
`readBfdName` was removed recently.
Pull in r352606 from upstream lld trunk (by me):
Recognize FreeBSD specific BFD names in OUTPUT_FORMAT
Summary:
After rLLD344952 ("Add OUTPUT_FORMAT linker script directive
support"), using BFD names such as `elf64-x86-64-freebsd` the
`OUTPUT_FORMAT` linker script command does not work anymore,
resulting in errors like:
```
ld: error: /home/dim/src/clang800-import/stand/efi/loader/arch/amd64/ldscript.amd64:2: unknown output format name: elf64-x86-64-freebsd
>>> OUTPUT_FORMAT("elf64-x86-64-freebsd", "elf64-x86-64-freebsd", "elf64-x86-64-freebsd")
>>> ^
```
To fix this, recognize a `-freebsd` suffix in BFD names, and also set
`Configuration::OSABI` to `ELFOSABI_FREEBSD` for those cases.
Add and/or update several test cases to check for the correct results
of these new `OUTPUT_FORMAT` arguments.
Reviewers: ruiu, atanasyan, grimar, hokein, emaste, espindola
Reviewed By: ruiu
Subscribers: nemanjai, javed.absar, arichardson, krytarowski, kristof.beyls, kbarton, llvm-commits
Differential Revision: https://reviews.llvm.org/D57283
FreeBSD previously defaulted to DWARF 2 because several tools (gdb,
ctfconvert, etc.) did not support later versions. These have either
been fixed or are deprecated.
Note that gdb 6 still exists but has been moved out of $PATH into
/usr/libexec and is intended only for use by crashinfo(8). The kernel
build sets the DWARF version explicitly via -gdwarf2, so this should
have no effect there.
PR: 234887 [exp-run]
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D17930
7.0.1 release r349250. There were no functional changes since the 7.0.1
rc3 import.
PR: 230240, 230355
Relnotes: yes
MFC after: 2 months
X-MFC-With: r341825
Don't mess up RelIplt symbols during relocatable processing
Summary:
During upgrading of the FreeBSD source tree with lld 7.0.0, I noticed
that it started complaining about crt1.o having an "index past the
end of the symbol table".
Such a symbol table looks approximately like this, viewed with
readelf -s (note the Ndx field being messed up):
Symbol table '.symtab' contains 4 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 SECTION LOCAL DEFAULT 1
2: 00000000 0 NOTYPE WEAK HIDDEN RSV[0xffff] __rel_iplt_end
3: 00000000 0 NOTYPE WEAK HIDDEN RSV[0xffff] __rel_iplt_start
At first, it seemed that recent ifunc relocation work had caused this:
<https://reviews.freebsd.org/rS339351>, but it turned out that it was
due to incorrect processing of the object files by lld, when using -r
(a.k.a. --relocatable).
Bisecting showed that rL324421 ("Convert a use of Config->Static") was
the commit where this new behavior began. Simply reverting it solved
the issue, and the __rel_iplt symbols had an index of UND again.
Looking at Rafael's commit message, I think he simply missed the
possibility of --relocatable being in effect, so I have added an
additional check for it.
I also added a simple regression test case.
Reviewers: grimar, ruiu, emaste, espindola
Reviewed By: ruiu
Subscribers: arichardson, krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D53515
This fixes a problem in lld where it places incorrect indexes for ifunc
related symbols in crt1.o and friends, making it impossible to link most
normal programs with it.
ELF spec says that for SHT_REL and SHT_RELA sh_link should reference the
associated string table and sh_info should reference the "section to
which the relocation applies." ELF Tool Chain's elfcopy / strip use
this (in part) to control whether or not the relocation entry is copied
to the output.
LLVM PR 37538 https://bugs.llvm.org/show_bug.cgi?id=37538
Approved by: re (kib)
Obtained from: llvm r344226 (backported for 6.0)
Previously Clang required ifunc resolution functions to take no
arguments, presumably because GCC documented ifunc resolvers as taking
no arguments. However, GCC accepts resolvers accepting arguments, and
our rtld passes CPU ID information (cpuid, hwcap, etc.) to ifunc
resolvers. Just remove the check from the in-tree compiler for our in-
tree compiler; a different (per-OS) approach may be required upstream.
Reported by: mjg
Approved by: re (rgrimes)
MFC after: 1 week
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
[ELF] - Allow LLD to produce file symbols.
This is for PR36716 and
this enables emitting STT_FILE symbols.
Output size affect is minor:
lld binary size changes from 52,883,408 to 52,949,400
clang binary size changes from 83,136,456 to 83,219,600
Differential revision: https://reviews.llvm.org/D45261
This fixes a regression in lld that made it stop emitting STT_FILE
symbols, which ctfmerge relies upon to uniquify function table entries
that reference STB_LOCAL symbols. Consequently, ctfmerge stopped
emitting entries for static functions into the function table, and
dtrace no longer gets type info for them.
Approved by: re (kib)
Reported by: markj
PR: 230444
MFC after: 3 days
[CodeGen] Initialize large arrays by copying from a global
Currently, clang compiles explicit initializers for array elements
into series of store instructions. For large arrays of built-in types
this results in bloated output code and significant amount of time
spent on the instruction selection phase. This patch fixes the issue
by initializing such arrays with global constants that store the
binary image of the initializer.
Differential Revision: https://reviews.llvm.org/D43181
This should fix a compiler hang (and excessive memory usage) while
building the science/rmg port.
Approved by: re (kib)
Reported by: yuri@tsoft.com
See also: https://bugs.llvm.org/show_bug.cgi?id=38798
MFC after: 3 days
