Commit Graph

11 Commits

Author SHA1 Message Date
Konstantin Belousov
e5c3405ce8 Align initial-exec TLS segments to the p_vaddr % align.
This is continuation of D21163/r359634, which handled the alignment
for global mode.

Non-x86 arches are not handled, maintainers are welcomed.

Tested by:	emaste
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D24366
2020-04-19 09:28:59 +00:00
Andrew Turner
6e4fdb5c9d Add STT_GNU_IFUNC and R_AARCH64_IRELATIVE support on arm64.
This is based on the amd64 implementation. Support for both PLT and
non-PLT (e.g. a global variable initilised with a pointer to an ifunc)
cases are supported.

We don't pass anything to the resolver as it is expected they will read
the ID registers directly, with the number of registers with CPU info
likely to increase in the future.

Reviewed by:	kib
Approved by:	re (gjb)
Differential Revision:	https://reviews.freebsd.org/D17341
2018-10-01 14:02:29 +00:00
Brooks Davis
17fb2856c3 Rework rtld's TLS Variant I implementation to match r326794
The above commit fixed handling overaligned TLS segments in libc's
TLS Variant I implementation, but rtld provides its own implementation
for dynamically-linked executables which lacks these fixes.  Thus,
port these changes to rtld.

This was previously commited as r337978 and reverted in r338149 due to
exposing a bug the ARM rtld.  This bug was fixed in r338317 by mmel.

Submitted by:	James Clarke
Approved by:	re (kib)
Reviewed by:	kbowling
Testing by:	kbowling (powerpc64), br (riscv), kevans (armv7)
Obtained from:	CheriBSD
Sponsored by:	DARPA, AFRL
Differential Revision:	https://reviews.freebsd.org/D16510
2018-09-05 23:23:16 +00:00
Brooks Davis
a5207d3ef6 Revert r337978: Rework rtld's TLS Variant I implementation to match r326794
Michal Meloun reports that it breaks ctype (isspace()..) related
functions on armv7 so back out while we diagnose the issue.

Reported by:	Michal Meloun <melounmichal@gmail.com>
2018-08-21 18:22:12 +00:00
Brooks Davis
9b50d81646 Rework rtld's TLS Variant I implementation to match r326794
The above commit fixed handling overaligned TLS segments in libc's
TLS Variant I implementation, but rtld provides its own implementation
for dynamically-linked executables which lacks these fixes.  Thus,
port these changes to rtld.

Submitted by:	James Clarke
Reviewed by:	kbowling
Testing byL	kbowling (powerpc64), br (riscv), kevans (armv7)
Obtained from:	CheriBSD
Sponsored by:	DARPA, AFRL
Differential Revision:	https://reviews.freebsd.org/D16510
2018-08-17 16:19:47 +00:00
Konstantin Belousov
e35ddbe448 Implement LD_BIND_NOT knob for rtld.
From the manpage:
When set to a nonempty string, prevents modifications of the PLT slots
when doing bindings.  As result, each call of the PLT-resolved
function is resolved.  In combination with debug output, this provides
complete account of all bind actions at runtime.

Same feature exists on Linux and Solaris.

Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
2017-03-15 21:11:57 +00:00
Ed Maste
eeef183376 Retire long-broken/unused static rtld support
rtld-elf has some vestigial support for building as a static executable.
r45501 introduced a partial implementation with a prescient note that it
"might never be enabled." r153515 introduced ELF symbol versioning
support, and removed part of the unused build infrastructure for static
rtld.

GNU ld populates rela relocation addends and GOT entries with the same
values, and rtld's run-time dynamic executable check relied on this.
Alternate toolchains may not populate the GOT entries, which caused
RTLD_IS_DYNAMIC to return false. Simplify rtld by just removing the
unused check.

If we want to restore static rtld support later on we ought to introduce
a build-time #ifdef flag.

PR:		214972
Reviewed by:	kan
MFC after:	1 month
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D8687
2016-12-02 14:23:26 +00:00
Konstantin Belousov
4352999e0e Pass CPUID[1] %edx (cpu_feature), %ecx (cpu_feature2) and
CPUID[7].%ebx (cpu_stdext_feature), %ecx (cpu_stdext_feature2) to the
ifunc resolvers on x86.

It is much more clean to use CPUID instruction in usermode to retrieve
this information than to pass AT_HWCAP aux vector from kernel, on
x86.  Still, the change does allow for use of AT_HWCAP on arches where it is
needed, by passing aux array to ifunc_init() initializer which should
prepare arguments for ifunc resolvers.

Current signature for resolvers on x86 is
	func_t iresolve(uint32_t cpu_feature, uint32_t cpu_feature2,
	    uint32_t cpu_stdext_feature, uint32_t cpu_stdext_feature2);
where arguments have identical meaning as the kernel variables of the
same name.  The ABIs allow to use resolvers with the void or shortened
list of arguments.

Reviewed by:	jhb
Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
Differential revision:	https://reviews.freebsd.org/D8448
2016-11-15 09:43:26 +00:00
Warner Losh
8fd53f4577 Create a generalized exec hook that different architectures can hook
into if they need to, but default to no action.

Differential Review: https://reviews.freebsd.org/D2718
2016-01-03 04:32:02 +00:00
Andrew Turner
7c81294224 Fix how we place each objects thread local data. The code used was based
on the Variant II code, however arm64 uses Variant I. The former placed the
thread pointer after the data, pointing at the thread control block, while
the latter places these before said data.

Because of this we need to use the size of the previous entry to calculate
where to place the current entry. We also need to reserve 16 bytes at the
start for the thread control block.

This also fixes the value of TLS_TCB_SIZE to be correct. This is the size
of two unsigned longs, i.e. 2 * 8 bytes.

While here remove the bogus adjustment of the pointer in the
R_AARCH64_TLS_TPREL64 case. It should be the offset of the data relative
to the thread pointer, including the thread control block.

Sponsored by:	ABT Systems Ltd
2015-09-01 15:57:03 +00:00
Andrew Turner
047c6e3ae6 Add the arm64 code to the runtime linker. It's not able to be built as we
still need libc_pic for a few things, but this is expected to be ready
soon.

Differential Revision:	https://reviews.freebsd.org/D2136
Reviewed by:	kib
Sponsored by:	The FreeBSD Foundation
2015-03-31 09:51:19 +00:00