From owner-freebsd-arm@freebsd.org Fri Feb 17 08:14:51 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DD70ACE2C96 for ; Fri, 17 Feb 2017 08:14:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-76.reflexion.net [208.70.210.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8BBCF161B for ; Fri, 17 Feb 2017 08:14:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23078 invoked from network); 17 Feb 2017 08:14:44 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 17 Feb 2017 08:14:44 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.0) with SMTP; Fri, 17 Feb 2017 03:14:44 -0500 (EST) Received: (qmail 24471 invoked from network); 17 Feb 2017 08:14:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 17 Feb 2017 08:14:43 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 316EDEC7B43; Fri, 17 Feb 2017 00:14:43 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: arm64 libc.so.7.full link: Are the 8 "R_AARCH64_ABS64 used with TLS symbol . . ." notices a problem? Message-Id: Date: Fri, 17 Feb 2017 00:14:42 -0800 To: freebsd-arm , FreeBSD Toolchain X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 08:14:52 -0000 [This happens to be a amd64 -> arm64 cross build context.] Context: # uname -paKU FreeBSD FreeBSDx64 12.0-CURRENT FreeBSD 12.0-CURRENT r313783M amd64 = amd64 1200020 1200020 In exploring how to investigate tsd_booted assert failures I noticed the following in: /usr/obj/pine64_clang/arm64.aarch64/usr/src/lib/libc/libc.so.7.full.meta # Meta data file = /usr/obj/pine64_clang/arm64.aarch64/usr/src/lib/libc/libc.so.7.full.meta CMD @echo building shared library libc.so.7 CMD @rm -f libc.so.7 libc.so CMD cc -B/usr/local/aarch64-freebsd/bin/ -mcpu=3Dcortex-a53 -target = aarch64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/pine64_clang/arm64.aarch64/usr/src/tmp = -B/usr/local/aarch64-freebsd/bin/ -nodefaultlibs = -Wl,--version-script=3DVersion.map -shared -Wl,-x -Wl,--fatal-warnings = -Wl,--warn-shared-textrel -o libc.so.7.full -Wl,-soname,libc.so.7 = `NM=3D'/usr/local/aarch64-freebsd/bin/nm' NMFLAGS=3D'' lorder = bt_close.pico . . . (long list of .pico files) . . . wmemset.pico | tsort -q` -lcompiler_rt -lssp_nonshared CWD /usr/obj/pine64_clang/arm64.aarch64/usr/src/lib/libc TARGET libc.so.7.full -- command output -- building shared library libc.so.7 /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x3b): = R_AARCH64_ABS64 used with TLS symbol udb /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x58): = R_AARCH64_ABS64 used with TLS symbol uf /usr/local/aarch64-freebsd/bin/ld: utxdb.pico(.debug_info+0x5a): = R_AARCH64_ABS64 used with TLS symbol futx_to_utx.ut /usr/local/aarch64-freebsd/bin/ld: jemalloc_tsd.pico(.debug_info+0x3c): = R_AARCH64_ABS64 used with TLS symbol __je_tsd_tls /usr/local/aarch64-freebsd/bin/ld: = jemalloc_tsd.pico(.debug_info+0x146e): R_AARCH64_ABS64 used with TLS = symbol __je_tsd_initialized /usr/local/aarch64-freebsd/bin/ld: = cxa_thread_atexit_impl.pico(.debug_info+0x3b): R_AARCH64_ABS64 used with = TLS symbol dtors /usr/local/aarch64-freebsd/bin/ld: xlocale.pico(.debug_info+0x403): = R_AARCH64_ABS64 used with TLS symbol __thread_locale /usr/local/aarch64-freebsd/bin/ld: setrunelocale.pico(.debug_info+0x3c): = R_AARCH64_ABS64 used with TLS symbol _ThreadRuneLocale Are these R_AARCH64_ABS64 notices expected? Are they a problem? I also notice that the "filemon acquired metadata" does not list an entry to match up with: /usr/src/lib/libc/stdlib/jemalloc/Symbol.map So it would appear that changes to the Symbol.map file would not of themselves cause things to rebuild or relink. =3D=3D=3D Mark Millard markmi at dsl-only.net