From nobody Wed Nov 20 16:29:42 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Xtmzq0Y06z5dSj2 for ; Wed, 20 Nov 2024 16:29:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-19.consmr.mail.gq1.yahoo.com (sonic313-19.consmr.mail.gq1.yahoo.com [98.137.65.82]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Xtmzn6QGLz4H9M for ; Wed, 20 Nov 2024 16:29:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=ECs00BiP; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1732120196; bh=X2Fvn8NAWBMFa3096q+Nnv7y1IaTP4poVEa2gSAoCLw=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From:Subject:Reply-To; b=ECs00BiPcjDMDOgEIDi00zD9mi4YSPx0DHxPhNvey9t9dNnDOgY/VenODHFbRVE8L+nQo/LnDbHZQAlZMuJai8RptkZ12K0poXZhOeT5bxwiJj/kTzFkzYO5bNn5J8C++J2pR9uUXVjgbClvOt6UZq2J9vd+s9hzNyZAqun/ist3locfiyurqOXxZt3s0jSphv6c+dA4ApHgEH/1/EuHhdItREkFgrGWSsEo0n5X/wfYC4pXLJZAMA0Q5j+TX1qzMQ9A74vLQXrNLKZFmrXpaihKaZzAGnN7flm7HRfI0kRMs04D8LCZrSs6YQ36KHXwE2AK99inQVA/VzyKMLWsmA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1732120196; bh=FEEZHTiBryz5R7poltR+MMlyIItZZfqTrEm74hbMsRX=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=ZJLTPAVC7NAHPTpgT3whQSYS/VXb+0trADciYh8iWMDGudvnRIcfStm3gGA3x4g33C7OplfdgyNzLep2O59YsoQy2pZOiRtwBIxngWM6b1wFdvD1w1PobtsYv1qeLpuqsefgkxBwVEVeQg5zCOp7aWo5oK+dOTsjZucjnV3rSIlNrnuTpyvCCOuMYZkrICWu7547hiYIpQT2LibSkuLwzhvaNzwRbzjbUqyS46ra367ofFkEeyBJ4J8RLNdnYiMgTZ/CrENomGwP163YvMbYa+laepBBhU3UOMNCz51rv8dTP3ZShiZiwJ5aXTUSS45AUsJt0AmCi5wxUWgaH5bKWw== X-YMail-OSG: GqouuHgVM1keJT5JddK7FIY8OCyZOohM1Yl6gWBK5twvfue2uEsnzER665It.DH SP6.9pYFNqZ9KuExsl9hnoMXbh5swWTy.rkaP7wX1voLURXpoKvh20GBs1La_xSnPPyDKZRQ0yx3 KzoQi1kYW_SEQ4i.4.q6oZdyu.KY8ys1GsCk3KsNA3aFFwkvwXRsSPsE9yDBtEi.n0VJmVOvN9Ve AGuuBAO3senugVvCkFgIkBZMkdzFxaZnvMmBbsXJfj.UPMWUGqIp92wJ6NInexNeG4XqsevyqOeM MCKdO98g_1DO4Dd5ZvmUUlVD17j8atnhElCOGyGHU5vx45ChaOqNjIfr.ngqagWC3r16co99axyI TunIwetNMVcSx3XxOXoGyVgiu1WzoD.YUEBwPzOoFkK6WXihZgvLFz79x63LVukGASnUgARNDbJK JqOwQxy6YB51yGaEMzcS3IQalkmdQmVPtT_mCQFkFNn4F.5wfAT3Ty0LfanrUTQdhir_Gg1dQLaL HWYU.0W0cHtKxKDzsab6xabfp46YH1miOJT2WOskAPONU1Qs72rHGngInO.hduxWkKE0NwR44uSe jfxYOm0btFk6xLDzlMBqZkBQhmftuPpbixl_uQ7K.eeG_XIZNZTeVkGetJe_7OfLIBXH9THiqQqL vnkwHZ8okgsimPQEDD0CBuUyAy.1Yvp.KaOgcxP39iMXNMx1cM5UprF1JuQGxend1Nh1jgq.26rT FTNmpygYCkRGvYUSfRF0Rt7FmFDWwGuAH9c9txQfARYK7UjTFxwHc0CArbdHfpcQ4s_W_SnepzRc mTkwykSFy_yJAbZiHFTEBuf14Jux_iVyC2bm1ngVIlQNfVHuUSlNiVDqS4daehDpIZlNUkedLB8A qyKDpG8JXCYUWd9QO__FppU.GfZflfq4icnUwl.pifKSf_1Rsq2a8362BhH0pg8.HOZuydRa46RD GQ.F0PPsUcYc6chgLW95aRjs5EacBZCpD6BfyRaCBnBvn4vNgEi35BbPtGwMVfMwpnaHHbboQdiP cNWlg_C5oFuQ7fs5gF5TU0BxJxptXxVphlR_8rOwd2VemSQadoRlg3rtGfcyF7hvsR83BsMbp_tZ QZazAkhDOPidliv8XAy4waQ9zpk9ISEIXkA5o.TO4t4VV.rBAxr_ddnVagF7R8.BFvfwL6igKAIz 3uN9xN_Lr1D.cc8fGVu67HnPwSBMBti_tFt7VZZbnz91n6q6wK_xAID5YywecedAOMfGazz2f0Fc fa01.2kKsxoSzpDonqIqaN0eo0rezH9tAnH8Li7IGBjPfLKjO2feN3uWXdpzhbfsp569XsNMhavj JRx1NzWeAmSjk0H6plb8VVrdaqMk.UOuych6iop6.it.4jmlkf2Bjzbam_xVj4DpWcDGDPFmUw7M xk4z3BCFJQwqVriRBo.3u99v0Bop45wloFMFaqtzVm9AVuvI5XZJfXZoLPaqtydJ1Tnpmks5GOyA fIYo.KqvVgoRISeMXEv8w_7czOGgYC4WbCdhT81Kb2xoDiig9IKE.A_G8OYus71XaCqQNFmPWqhe 8Sfiv5GhEwgdCobo4U7RlE8SKcD6NaV_iXpgMRptt8XmpkWgzvad2WGyavWEDNgM1fn2XzqOd_6P berigNcPCt6SP1q6mSwyI6ov0FXqnAGfWf2B1.uuqHk9lTmlGYJ4PVSQUMPrRW.mNRHzcGS3q5nX dP0BZNrDD6co3q50IewPyxMGJPtHXUAFP.bHJh1kA203LLl2BwB9ovRiA_2U3QPhq468v1xLBbYt cHQ.eHIEVk8S6KKwAgugwCrHhhglszMDt5wDiW9S5u6qTbygB1fDeJCQ.ZqpCfseD0Sbtm9L1E2x gkVFC5fLkkNpGfc2cBe.NHNMv_thIGsWKE7sY4fijOG.7qsIvGAkwHtI26rVCUyZjqr8GNVqUvmA mY6Zi4bxhi_cnKhkNtOsmB3LWUBaJb4uVVYmKL6FNkJTzr3hggR2gjUUZIjxsCoY0If55ckVQP4E f2cYtJUitfjFcgF0HgeYQA02n10YMbIGh1KdtKnQ_._IJMWXi3pj2z7zFnnRtzPWe2JqDP7TZYXW 4aBPIFdRA45tqPe0KAV2tcsZOMpv1sfor6MWNka7uYbKBHF7ZAvigcRkgQdOkRBRLH9Hh_CohL7m _OQuUQxMODhbiA_7y_CyPB9AGehjoGNyAAL97JXGsUb7c82nO3EQ._018NL8_uLhFUU08AfrFQ.m S5exQ1p89yPurp4lwayQ0Ktv8BcZeBIIPN8Bjki.w_d02jm2tzUCPC7vdMlaMqDfuOXUowjc2gsf 5tKIh4mnrhQ_KoLo- X-Sonic-MF: X-Sonic-ID: d1f0c9fb-63ca-4826-b6f9-e73f79c087a7 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Wed, 20 Nov 2024 16:29:56 +0000 Received: by hermes--production-gq1-5dd4b47f46-5kxd4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 028dc3a2dcf3d6919cc9af8302f6555c; Wed, 20 Nov 2024 16:29:53 +0000 (UTC) From: Mark Millard Message-Id: <7E60FC8D-1770-444F-A4FA-953A2A2FEDB8@yahoo.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_294CD89F-DEEB-4FB5-89D5-BE573B9F8557" List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: Should stable/1[34] and supported 1[34].*-RELEASE have -ftls-model=initial-exec fixes MFC'd and/or EC'd for armv7? Date: Wed, 20 Nov 2024 08:29:42 -0800 In-Reply-To: Cc: Jessica Clarke To: FreeBSD-STABLE Mailing List , FreeBSD ARM List References: X-Mailer: Apple Mail (2.3776.700.51) X-Spamd-Result: default: False [-2.99 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.99)[-0.992]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.82:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.82:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4Xtmzn6QGLz4H9M X-Spamd-Bar: -- --Apple-Mail=_294CD89F-DEEB-4FB5-89D5-BE573B9F8557 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [Just CC'ing Jessica C. instead of kib. This is based on = https://reviews.freebsd.org/D42415 having Jessica's note: If IE is fixed then lib/libc/Makefile probably should enable it on arm = as a follow-up, which I *think* is the only architecture not covered by = that if statement, unless I'm missing something ] On Nov 17, 2024, at 10:50, Mark Millard wrote: [Not that they could be timed for 14.2-RELEASE at this point.] Given an update to the bootstrap lang/rust compiler that has already been fixed, the below fixes why lang/rust has not built on the official package build server s for 1[34].* since at least lang/rust 1.77.0 . (The traceable records do not go back beyond that. But it may be that rust became dependent at 1.77.0 for all I know.) It also blocks private armv7 lang/rust builds for stable/1[34] . Other packages may have build failures that are related but I'll use the lang/rust activity here: used as the test case. I have locally tested building lang/rust 1.82.0_1 on stable/14 both with and without the changes in question. With the 2 commits it built just fine, unlike without. (I did not try just 1 of the 2, just the pair as I unit.) The primary, recent bugzilla activity is at: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D282663 But the below avoids going through the discovery process and history that is recorded there. (There are also other related bugzilla's around but this one is where the potential MFC's were identified.) See also the fallout records for lang/rust for armv7: = https://portsfallout.com/fallout?port=3Dlang%2Frust&maintainer=3D&env=3Dar= mv7&category=3D&flavor=3D (but ignore the lang/rustpython lines that also match the pattern used). Only main got the fixes back in 2023-Nov and only main has worked for lang/rust for the official armv7 package build servers since then for any records that I've found -- lang/rust 1.77.0 and later. The 2 commits are: = https://cgit.freebsd.org/src/commit/?id=3D98fd69f0090da73d9d0451bd769d7752= 468284c6 = https://cgit.freebsd.org/src/commit/?id=3D6e5b1ff71e01bd48172483cb6df921f8= 4300ea3a I show the details below. Whitespace might not be accurately preserved = below. https://cgit.freebsd.org/src/commit/?id=3D98fd69f0090d is: author R. Christian McDonald 2023-11-03 12:56:58 +0000 committer Kristof Provost 2023-11-03 21:43:40 +0000 . . . rtld/arm: fix initial-exec (IE) thread-local storage relocation net/frr[89] revealed an interesting edge-case on arm when dynamically linking a shared library that declares more than one static TLS variable with at least one using the "initial-exec" TLS model. In the case of frr[89], this library was libfrr.so which essentially does the following: #include #include "lib.h" static __thread int *a __attribute__((tls_model("initial-exec"))); void lib_test() { static __thread int b =3D -1; printf("&a =3D %p\n", &a); printf(" a =3D %p\n", a); printf("\n"); printf("&b =3D %p\n", &b); printf(" b =3D %d\n", b); } Allocates a file scoped `static __thread` pointer with tls_model("initial-exec") and later a block scoped TLS int. Notice in the above minimal reproducer, `b =3D=3D -1`. The relocation process does the wrong thing and ends up pointing both `a` and `b` at the same place in memory. The output of the above in the broken state is: &a =3D 0x4009c018 a =3D 0xffffffff &b =3D 0x4009c018 b =3D -1 With the patch applied, the output becomes: &a =3D 0x4009c01c a =3D 0x0 &b =3D 0x4009c018 b =3D -1 Reviewed by: kib Sponsored by: Rubicon Communications, LLC ("Netgate") Differential Revision: https://reviews.freebsd.org/D42415/ Diffstat -rw-r--r-- libexec/rtld-elf/arm/reloc.c 7=09 1 files changed, 5 insertions, 2 deletions diff --git a/libexec/rtld-elf/arm/reloc.c b/libexec/rtld-elf/arm/reloc.c index c3e95940be74..6efc9f499761 100644 --- a/libexec/rtld-elf/arm/reloc.c +++ b/libexec/rtld-elf/arm/reloc.c @@ -280,10 +280,13 @@ reloc_nonplt_object(Obj_Entry *obj, const Elf_Rel = *rel, SymCache *cache, return -1; tmp =3D (Elf_Addr)def->st_value + = defobj->tlsoffset; - if (__predict_true(RELOC_ALIGNED_P(where))) + if (__predict_true(RELOC_ALIGNED_P(where))) { + tmp +=3D *where; *where =3D tmp; - else + } else { + tmp +=3D load_ptr(where); store_ptr(where, tmp); + } dbg("TLS_TPOFF32 %s in %s --> %p", obj->strtab + obj->symtab[symnum].st_name, obj->path, (void *)tmp); https://cgit.freebsd.org/src/commit/?id=3D6e5b1ff71e01 is: author R. Christian McDonald 2023-11-09 20:22:21 = +0000 committer Kristof Provost 2023-11-09 = 20:24:23 +0000 . . . Reviewed by: kib Sponsored by: Rubicon Communications, LLC ("Netgate") Differential Revision: https://reviews.freebsd.org/D42415/ libc: enable initial-exec (IE) as default thread-local storage model on = arm As suggested by jrtc27@ in https://reviews.freebsd.org/D42415, this patch enables IE as default thread-local storage model in libc on arm. Reviewed by: kib Sponsored by: Rubicon Communications, LLC ("Netgate") Differential Revision: https://reviews.freebsd.org/D42445 Diffstat -rw-r--r-- lib/libc/Makefile 4=09 1 files changed, 0 insertions, 4 deletions diff --git a/lib/libc/Makefile b/lib/libc/Makefile index 7540eb8c21ad..e817104642b8 100644 --- a/lib/libc/Makefile +++ b/lib/libc/Makefile @@ -54,11 +54,7 @@ CFLAGS+=3D${CANCELPOINTS_CFLAGS} # Use a more efficient TLS model for libc since we can reasonably assume = that # it will be loaded during program startup. -.if ${LIBC_ARCH} =3D=3D "aarch64" || ${LIBC_ARCH} =3D=3D "amd64" || \ - ${LIBC_ARCH} =3D=3D "i386" || ${LIBC_ARCH} =3D=3D "riscv" || \ - ${LIBC_ARCH:Mpowerpc*} !=3D "" CFLAGS+=3D -ftls-model=3Dinitial-exec -.endif # # Link with static libcompiler_rt.a. =3D=3D=3D Mark Millard marklmi at yahoo.com =3D=3D=3D Mark Millard marklmi at yahoo.com --Apple-Mail=_294CD89F-DEEB-4FB5-89D5-BE573B9F8557 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii [Just CC'ing = Jessica C. instead of kib. This is based on https://reviews.freebsd.org/D4= 2415
having Jessica's note:

If IE is fixed then = lib/libc/Makefile probably should enable it on arm as a follow-up, which = I *think* is the only architecture not covered by that if statement, = unless I'm missing something
]

On Nov 17, 2024, at = 10:50, Mark Millard <marklmi@yahoo.com> wrote:

[Not that they could be = timed for 14.2-RELEASE at this point.]

Given an update to the = bootstrap lang/rust compiler that has
already been fixed, the below = fixes why lang/rust has not
built on the official package build = server s for 1[34].* since
at least lang/rust 1.77.0 . (The = traceable
records do not go back beyond that. But it may be = that
rust  became dependent at 1.77.0 for all I know.) It = also
blocks private armv7 lang/rust builds for stable/1[34] = .

Other packages may have build failures that are related
but = I'll use the lang/rust activity here: used as the
test case.

I = have locally tested building lang/rust 1.82.0_1 on
stable/14 both = with and without the changes in question.
With the 2 commits it built = just fine, unlike without.
(I did not try just 1 of the 2, just the = pair as I unit.)

The primary, recent bugzilla activity is = at:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D282663
<= br>But the below avoids going through the discovery process = and
history that is recorded there. (There are also other = related
bugzilla's around but this one is where the potential = MFC's
were identified.)

See also the fallout records for = lang/rust for = armv7:

https://portsfallout.com/fallout?port=3Dlang%2Frust&main= tainer=3D&env=3Darmv7&category=3D&flavor=3D

(but = ignore the lang/rustpython lines that also match the pattern = used).


Only main got the fixes back in 2023-Nov and only main = has worked for
lang/rust for the official armv7 package build servers = since then
for any records that I've found -- lang/rust 1.77.0 and = later.


The 2 commits = are:

https://cgit.freebsd.org/src/commit/?id=3D98fd69f0090da73d9d04= 51bd769d7752468284c6

https://cgit.freebsd.org/src/commit/?id=3D6e5b= 1ff71e01bd48172483cb6df921f84300ea3a

I show the details below. = Whitespace might not be accurately preserved = below.


https://cgit.freebsd.org/src/commit/?id=3D98fd69f0090d = is:

author R. Christian McDonald <rcm@rcm.sh> 2023-11-03 = 12:56:58 +0000
committer Kristof Provost <kp@FreeBSD.org> = 2023-11-03 21:43:40 +0000
. . .

rtld/arm: fix initial-exec = (IE) thread-local storage relocation

net/frr[89] revealed an = interesting edge-case on arm when dynamically
linking a shared = library that declares more than one static TLS variable
with at least = one  using the "initial-exec" TLS model. In the case
of frr[89], = this library was libfrr.so which essentially does = the
following:

#include = <stdio.h>

#include "lib.h"

static = __thread int *a
= __attribute__((tls_model("initial-exec")));

void = lib_test()
= {
= = static __thread int b =3D -1;

printf("&a =3D %p\n", = &a);
= = printf(" a =3D %p\n", a);

printf("\n");

= printf("&b =3D %p\n", &b);
printf(" = b =3D %d\n", b);
}

Allocates a file scoped = `static __thread` pointer with
tls_model("initial-exec") and later a = block scoped TLS int. Notice in
the above minimal reproducer, `b =3D=3D= -1`. The relocation process does
the wrong thing and ends up = pointing both `a` and `b` at the same place
in memory.

The = output of the above in the broken state is:

&a =3D = 0x4009c018
= a =3D 0xffffffff

&b =3D 0x4009c018
b =3D = -1

With the patch applied, the output becomes:

&a =3D = 0x4009c01c
= a =3D 0x0

&b =3D 0x4009c018
b =3D = -1

Reviewed by: kib
Sponsored by: Rubicon Communications, LLC = ("Netgate")
Differential Revision: = https://reviews.freebsd.org/D42415/

Diffstat
-rw-r--r-- = libexec/rtld-elf/arm/reloc.c 7
1 files changed, 5 = insertions, 2 deletions
diff --git a/libexec/rtld-elf/arm/reloc.c = b/libexec/rtld-elf/arm/reloc.c
index c3e95940be74..6efc9f499761 = 100644
--- a/libexec/rtld-elf/arm/reloc.c
+++ = b/libexec/rtld-elf/arm/reloc.c
@@ -280,10 +280,13 @@ = reloc_nonplt_object(Obj_Entry *obj, const Elf_Rel *rel, SymCache = *cache,
= = = = return -1;

tmp =3D = (Elf_Addr)def->st_value + defobj->tlsoffset;
- if = (__predict_true(RELOC_ALIGNED_P(where)))
+ if = (__predict_true(RELOC_ALIGNED_P(where))) {
+ tmp +=3D = *where;
= = = = *where =3D tmp;
- else
+ } else = {
+ = = = = tmp +=3D load_ptr(where);
store_ptr(where, tmp);
+ }
= = = = dbg("TLS_TPOFF32 %s in %s --> %p",
=    obj->strtab + obj->symtab[symnum].st_name,
= = = =    obj->path, (void = *)tmp);


https://cgit.freebsd.org/src/commit/?id=3D6e5b1ff71e01 = is:

author= R. Christian McDonald <rcm@rcm.sh> = 2023-11-09 20:22:21 +0000
committer Kristof = Provost <kp@FreeBSD.org> 2023-11-09 20:24:23 +0000
. . = .

Reviewed by: kib
Sponsored by: Rubicon = Communications, LLC ("Netgate")
Differential Revision: = https://reviews.freebsd.org/D42415/

libc: enable = initial-exec (IE) as default thread-local storage model on arm

As = suggested by jrtc27@ in https://reviews.freebsd.org/D42415, = this
patch enables IE as default thread-local storage model in libc = on arm.

Reviewed by: kib
Sponsored by: Rubicon = Communications, LLC ("Netgate")
Differential Revision: = https://reviews.freebsd.org/D42445

Diffstat
-rw-r--r-- = lib/libc/Makefile 4
1 files changed, 0 = insertions, 4 deletions
diff --git a/lib/libc/Makefile = b/lib/libc/Makefile
index 7540eb8c21ad..e817104642b8 100644
--- = a/lib/libc/Makefile
+++ b/lib/libc/Makefile
@@ -54,11 +54,7 @@ = CFLAGS+=3D${CANCELPOINTS_CFLAGS}

# Use a more efficient TLS = model for libc since we can reasonably assume that
# it will be = loaded during program startup.
-.if ${LIBC_ARCH} =3D=3D "aarch64" || = ${LIBC_ARCH} =3D=3D "amd64" || \
-    ${LIBC_ARCH} =3D=3D= "i386" || ${LIBC_ARCH} =3D=3D "riscv" || \
- =    ${LIBC_ARCH:Mpowerpc*} !=3D ""
CFLAGS+=3D = -ftls-model=3Dinitial-exec
-.endif

#
# Link with static = libcompiler_rt.a.

=3D=3D=3D
Mark Millard
marklmi at = yahoo.com


=3D=3D=3D
Mark = Millard
marklmi at = yahoo.com

= --Apple-Mail=_294CD89F-DEEB-4FB5-89D5-BE573B9F8557--