From owner-freebsd-ports@freebsd.org Sat Nov 17 16:48:58 2018 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B6F31137EF9 for ; Sat, 17 Nov 2018 16:48:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-9.consmr.mail.gq1.yahoo.com (sonic307-9.consmr.mail.gq1.yahoo.com [98.137.64.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5942C71774 for ; Sat, 17 Nov 2018 16:48:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: XJcLY7EVM1mkd4OAmwA0kdD9C0tcMEyG_I07iwWFawGusYoYNT1e4666Je0LcRI YJwDT2rjIbtSijopr5BfODmvKzg1aeHPRAwXrQJcqPtzDAiW87lexuF6eh8Iz_V7M68S0ZTjfggr 7BafBRYB065y1ENK1yGB5gXcYg0H6aYMUn9gKElcie4ixfo3Rpsv8GXfLqKlupYIczussEFTSEu_ q_iNQWS1p4w2AqPLacEcnVPvTVC3X0O3xdg9jIt8nrm3S7b9Ygw9X5z9wWzCv2hVuyOs1iCS00s. tmRKjs7Gqg2pRolnLB3dppCiYL4HhQdMGLPxaSA0GECDaVWQhhjRvo_61EtGZuWEEieUcbS5aluP 3wlXqxzgZopqdbpi5af_2v74hKRQ9EmVlWEFiRNgkfsoDTEPCL_w0JbaImS8zABpogke168J4sYe vKXBw5scBk17ohvq204vjbf5s6rKl3BaWs1qToJahjK6YKqghOWqmHXvrUe7.KN5GwmW_gltuSxl fWPFhiKfYsPPsWN3kcuj4eyp2SqbWwjbnMuDt7Xl9Bz2OzKNlxMBwq2gOQ0BHbt2dOSuEhTmOoac hxF6XfpO706hDV6v0btXDu4wYNxFIlBDkMLRMS18gvBEP_sqy3sNzTK2.gvheT7SOESB9rAK.llJ D4KJwCCXDSmOVfqpymrGTrpIGl_CfpyQMN24RizvbJj30OMhzSOTfmdhiCr5Amkn.OExuMfGXsu5 kVi1xU8sgywP7DZ0UQgtkareanVyz03ddK5bfm1caHBWHs5bVURPdsNgsB0kbaC2sAboz8KpiEtu FZNNleG8aIbfjulIMslktHxR4OQvCoYRlNYzjKMsQ51Kv_eVtIKDCcDTHASFg13PIZlJ5JitK0rw tb0Kve41nHFuO_q6f6ugrtcz7R4s0aaV8z0XJdEg2zTrnKAdAiqNJWbCKQZcz7PUULwmfoe1HQi1 80RueYuaW_ZqhPelNQBhCJQxzHWk26MdCNUDe9ok2PcGcX0wGd2Zy5A8SCSpSlnafEJBDPyaui0M riOGTvVkPRO7_YGBiqacOzsw3cq3PP5aDjv9HHdTPjh.Ii1yHVExEdH8RPA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Sat, 17 Nov 2018 16:48:48 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp409.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7e09ac9d83a81f3fe90294f4adb224f2; Sat, 17 Nov 2018 16:48:46 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Subject: Re: ports head -r487783: on armv7 x11/pixman fails to build: /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local symbol in readonly segment; recompile object files with -fPIC [lld/trunk has afix] From: Mark Millard In-Reply-To: <4BEBC4A6-D9F2-4838-8DAB-4B494D4E0B0D@yahoo.com> Date: Sat, 17 Nov 2018 08:48:45 -0800 Cc: Jan Beich , ports-list freebsd Content-Transfer-Encoding: quoted-printable Message-Id: <872CB297-10D5-4A1C-B01F-B00A9256E9D2@yahoo.com> References: <03FFE5BB-777D-40D3-9AA3-C8C359BE1F2B@yahoo.com> <908FD96A-9F8F-4477-8E2F-2C97D49AF35E@yahoo.com> <4BEBC4A6-D9F2-4838-8DAB-4B494D4E0B0D@yahoo.com> To: FreeBSD Toolchain X-Mailer: Apple Mail (2.3445.101.1) X-Rspamd-Queue-Id: 5942C71774 X-Spamd-Result: default: False [0.96 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_FROM(0.00)[yahoo.com]; LONG_SUBJ(1.64)[218]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCVD_IN_DNSWL_NONE(0.00)[33.64.137.98.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.41)[-0.407,0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; IP_SCORE(0.25)[ipnet: 98.137.64.0/21(0.73), asn: 36647(0.59), country: US(-0.10)]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2018 16:48:58 -0000 [The update to lld/trunk/ELF/Arch/ARM.cpp will not fix what we have run into.] On 2018-Nov-16, at 19:35, Mark Millard wrote: > Such timing: https://reviews.llvm.org/D53444 indicates > commits to lld/trunk/ELF/Arch/ARM.cpp today (2018-Nov-16) > to support R_ARM_V4BX in lld. >=20 > (No update text below. The above just did not fit well.) >=20 > On 2018-Nov-16, at 18:49, Mark Millard wrote: >=20 >=20 >> On 2018-Nov-16, at 18:15, Mark Millard wrote: >>=20 >>>=20 >>> I finally figured out parts of the issue, I think. >>> At least how the V_ARM_V4BX use is getting there >>> despite lld's status for handling it . . . >>>=20 >>> On armv7: >>>=20 >>> # more test_bx_lr.S >>> .text >>> .arch armv6 >>> .object_arch armv4 >>> .arm >>> .altmacro >>> .p2align 2 >>> .func fname >>> .global fname >>> .hidden fname >>> .type fname, %function >>> fname: >>> bx lr >>>=20 >>> (I got those lines from the failing port's .S files, >>> including includes. Note the .object_arch armv4 use >>> and the forced armv6, not armv7.) >>=20 >> For reference relative to the use of .object_arch armv4 : >>=20 >> # grep -r object_arch = /wrkdirs/usr/ports/x11/pixman/work/pixman-0.34.0/pixman/ | more >> = /wrkdirs/usr/ports/x11/pixman/work/pixman-0.34.0/pixman/pixman-arm-neon-as= m.S: .object_arch armv4 >> = /wrkdirs/usr/ports/x11/pixman/work/pixman-0.34.0/pixman/pixman-arm-simd-as= m-scaled.S: .object_arch armv4 >> = /wrkdirs/usr/ports/x11/pixman/work/pixman-0.34.0/pixman/pixman-arm-neon-as= m-bilinear.S:.object_arch armv4 >> = /wrkdirs/usr/ports/x11/pixman/work/pixman-0.34.0/pixman/pixman-arm-simd-as= m.S: .object_arch armv4 >>=20 >> Without .object_arch armv4 the assembler involved does not output >> the V_ARM_V4BX *ABS* relocation records (adjusted the small example): >>=20 >> # objdump -x test_bx_lr.o | more >>=20 >> test_bx_lr.o: file format elf32-littlearm >> test_bx_lr.o >> architecture: arm, flags 0x00000010: >> HAS_SYMS >> start address 0x00000000 >> private flags =3D 5000000: [Version5 EABI] >>=20 >> Sections: >> Idx Name Size VMA LMA File off Algn >> 0 .text 00000004 00000000 00000000 00000034 2**2 >> CONTENTS, ALLOC, LOAD, READONLY, CODE >> 1 .data 00000000 00000000 00000000 00000038 2**0 >> CONTENTS, ALLOC, LOAD, DATA >> 2 .bss 00000000 00000000 00000000 00000038 2**0 >> ALLOC >> 3 .ARM.attributes 0000001b 00000000 00000000 00000038 2**0 >> CONTENTS, READONLY >> SYMBOL TABLE: >> 00000000 l d .text 00000000 .text >> 00000000 l d .data 00000000 .data >> 00000000 l d .bss 00000000 .bss >> 00000000 l d .ARM.attributes 00000000 .ARM.attributes >> 00000000 g F .text 00000000 .hidden fname >>=20 >>=20 >>=20 >>> # clang -target armv7-unknown-freebsd13.0-gnueabihf -O -pipe = -no-integrated-as -MT test_bx_lr.lo -MD -MP -MF test_bx_lr.Tpo -c = test_bx_lr.S -fPIC -DPIC -o test_bx_lr.o >>>=20 >>> (The -target is not necessary. I just choose to be explicit.) >>>=20 >>> # objdump -x test_bx_lr.o | more >>>=20 >>> test_bx_lr.o: file format elf32-littlearm >>> test_bx_lr.o >>> architecture: armv4, flags 0x00000011: >>> HAS_RELOC, HAS_SYMS >>> start address 0x00000000 >>> private flags =3D 5000000: [Version5 EABI] >>>=20 >>> Sections: >>> Idx Name Size VMA LMA File off Algn >>> 0 .text 00000004 00000000 00000000 00000034 2**2 >>> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE >>> 1 .data 00000000 00000000 00000000 00000038 2**0 >>> CONTENTS, ALLOC, LOAD, DATA >>> 2 .bss 00000000 00000000 00000000 00000038 2**0 >>> ALLOC >>> 3 .ARM.attributes 0000001b 00000000 00000000 00000038 2**0 >>> CONTENTS, READONLY >>> SYMBOL TABLE: >>> 00000000 l d .text 00000000 .text >>> 00000000 l d .data 00000000 .data >>> 00000000 l d .bss 00000000 .bss >>> 00000000 l d .ARM.attributes 00000000 .ARM.attributes >>> 00000000 g F .text 00000000 .hidden fname >>>=20 >>>=20 >>> RELOCATION RECORDS FOR [.text]: >>> OFFSET TYPE VALUE=20 >>> 00000000 R_ARM_V4BX *ABS* >>>=20 >>>=20 >>> truss for that cc command reports looking in many >>> places for as, finally finding /usr/local/bin/as : >>>=20 >>> access("/usr/bin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) = ERR#2 'No such file or directory' >>> access("/usr/bin/as",X_OK|R_OK) ERR#2 'No such = file or directory' >>>=20 >>> (Note: based on WITHOUT_BINUTILS=3D for buildworld the above would = normally >>> not be found. But for WITH_BINUTILS=3D the host as would be found.) >>>=20 >>> access("/sbin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) = ERR#2 'No such file or directory' >>> access("/bin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) = ERR#2 'No such file or directory' >>> access("/usr/sbin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) = ERR#2 'No such file or directory' >>> access("/usr/bin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) = ERR#2 'No such file or directory' >>> = access("/usr/local/sbin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK)= ERR#2 'No such file or directory' >>> = access("/usr/local/bin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) = ERR#2 'No such file or directory' >>> = access("/usr/home/markmi/bin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|= R_OK) ERR#2 'No such file or directory' >>> access("/sbin/as",X_OK|R_OK) ERR#2 'No such = file or directory' >>> access("/bin/as",X_OK|R_OK) ERR#2 'No such file or = directory' >>> access("/usr/sbin/as",X_OK|R_OK) ERR#2 'No such file or = directory' >>> access("/usr/bin/as",X_OK|R_OK) ERR#2 'No such = file or directory' >>> access("/usr/local/sbin/as",X_OK|R_OK) ERR#2 'No such = file or directory' >>> access("/usr/local/bin/as",X_OK|R_OK) =3D 0 (0x0) >>>=20 >>> (Note the = /usr/home/markmi/bin/armv7-unknown-freebsd13.0-gnueabihf-as attempt >>> before the one actually found and used. I would not have guessed the >>> need to worry about such a place.) >>>=20 >>> Then follows: >>>=20 >>> fstatat(AT_FDCWD,"/usr/local/bin/as",{ mode=3D-r-xr-xr-x = ,inode=3D80287,size=3D21817416,blksize=3D32768 },0x0) =3D 0 (0x0) >>> __sysctl(0xbfbfe020,0x2,0xbfbfe018,0xbfbfe01c,0xe,0x236c9140) =3D 0 = (0x0) >>> access("/usr/bin/clang",F_OK) =3D 0 (0x0) >>> vfork() =3D 61461 = (0xf015) >>> wait4(61461,{ EXITED,val=3D0 },0x0,0x0) =3D 61461 = (0xf015) >>> access("/usr/local/bin/as",F_OK) =3D 0 (0x0) >>> vfork() =3D 61462 = (0xf016) >>> wait4(61462,{ EXITED,val=3D0 },0x0,0x0) =3D 61462 = (0xf016) >>> access("/tmp/test_bx_lr-0c7bf8.s",W_OK) =3D 0 (0x0) >>> fstatat(AT_FDCWD,"/tmp/test_bx_lr-0c7bf8.s",{ mode=3D-rw-r--r-- = ,inode=3D802647,size=3D210,blksize=3D32768 },0x0) =3D 0 (0x0) >>> fstatat(AT_FDCWD,"/tmp/test_bx_lr-0c7bf8.s",{ mode=3D-rw-r--r-- = ,inode=3D802647,size=3D210,blksize=3D32768 },AT_SYMLINK_NOFOLLOW) =3D 0 = (0x0) >>> fstatat(AT_FDCWD,"/tmp/test_bx_lr-0c7bf8.s",{ mode=3D-rw-r--r-- = ,inode=3D802647,size=3D210,blksize=3D32768 },AT_SYMLINK_NOFOLLOW) =3D 0 = (0x0) >>> unlink("/tmp/test_bx_lr-0c7bf8.s") =3D 0 (0x0) >>>=20 >>> llvm/clang is not providing the assembler used for -no-integrated-as = . >>> This would appear to imply that a system without ports or other such >>> can not use -no-integrated-as with clang for buildworld buildkernel. >>>=20 >>> In my normal armv7 command line context the above ends up using: >>>=20 >>> # /usr/local/bin/as -v >>> GNU assembler version 2.30 (armv7-portbld-freebsd13.0) using BFD = version (GNU Binutils) 2.30 >>>=20 >>> So a GNU toolchain's as is actually in control of what goes in >>> the .o file in many contexts. It is not clear that all the >>> alternatives are equivalent for R_ARM_V4BX being generated >>> or not. >>>=20 >>>=20 >>> Simplifying the command (but still showing target): >>>=20 >>> # clang -target armv7-unknown-freebsd13.0-gnueabihf -pipe = -no-integrated-as -c test_bx_lr.S -o test_bx_lr.o >>>=20 >>> # objdump -x test_bx_lr.o | more >>>=20 >>> test_bx_lr.o: file format elf32-littlearm >>> test_bx_lr.o >>> architecture: armv4, flags 0x00000011: >>> HAS_RELOC, HAS_SYMS >>> start address 0x00000000 >>> private flags =3D 5000000: [Version5 EABI] >>>=20 >>> Sections: >>> Idx Name Size VMA LMA File off Algn >>> 0 .text 00000004 00000000 00000000 00000034 2**2 >>> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE >>> 1 .data 00000000 00000000 00000000 00000038 2**0 >>> CONTENTS, ALLOC, LOAD, DATA >>> 2 .bss 00000000 00000000 00000000 00000038 2**0 >>> ALLOC >>> 3 .ARM.attributes 0000001b 00000000 00000000 00000038 2**0 >>> CONTENTS, READONLY >>> SYMBOL TABLE: >>> 00000000 l d .text 00000000 .text >>> 00000000 l d .data 00000000 .data >>> 00000000 l d .bss 00000000 .bss >>> 00000000 l d .ARM.attributes 00000000 .ARM.attributes >>> 00000000 g F .text 00000000 .hidden fname >>>=20 >>>=20 >>> RELOCATION RECORDS FOR [.text]: >>> OFFSET TYPE VALUE=20 >>> 00000000 R_ARM_V4BX *ABS* >>>=20 >>>=20 >>> Without the -no-integrated-as the notation in the file is rejected, >>> with "unknown directive" for .func . >>>=20 >>>=20 >>>=20 >>> Using poudriere bulk with -i and installing binutils in the >>> session, I see the same inside my amd64->armv7 cross build >>> environment. So there still is the question of how R_ARM_V4BX >>> is handled by various lld's in various contexts. (Or whatever >>> linker is being used if it is not lld.) >>>=20 >>> Back to amd64 land . . . >>>=20 >>> Renaming the existing as files so we can see all the places >>> searched before not-found is declared (on amd64 with -target >>> specified): >>>=20 >>> access("/usr/bin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) = ERR#2 'No such file or directory' >>> access("/usr/bin/as",X_OK|R_OK) ERR#2 'No such = file or directory' >>> access("/usr/bin/x86_64-unknown-freebsd13.0-as",X_OK|R_OK) ERR#2 'No = such file or directory' >>> access("/sbin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) = ERR#2 'No such file or directory' >>> access("/bin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) = ERR#2 'No such file or directory' >>> access("/usr/sbin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) = ERR#2 'No such file or directory' >>> access("/usr/bin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) = ERR#2 'No such file or directory' >>> = access("/usr/local/sbin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK)= ERR#2 'No such file or directory' >>> = access("/usr/local/bin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) = ERR#2 'No such file or directory' >>> = access("/usr/home/markmi/bin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|= R_OK) ERR#2 'No such file or directory' >>> access("/sbin/as",X_OK|R_OK) ERR#2 'No such = file or directory' >>> access("/bin/as",X_OK|R_OK) ERR#2 'No such file or = directory' >>> access("/usr/sbin/as",X_OK|R_OK) ERR#2 'No such file or = directory' >>> access("/usr/bin/as",X_OK|R_OK) ERR#2 'No such = file or directory' >>> access("/usr/local/sbin/as",X_OK|R_OK) ERR#2 'No such = file or directory' >>> access("/usr/local/bin/as",X_OK|R_OK) ERR#2 'No such = file or directory' >>> access("/usr/home/markmi/bin/as",X_OK|R_OK) ERR#2 'No such file or = directory' >>> access("/sbin/x86_64-unknown-freebsd13.0-as",X_OK|R_OK) ERR#2 'No = such file or directory' >>> access("/bin/x86_64-unknown-freebsd13.0-as",X_OK|R_OK) ERR#2 'No = such file or directory' >>> access("/usr/sbin/x86_64-unknown-freebsd13.0-as",X_OK|R_OK) ERR#2 = 'No such file or directory' >>> access("/usr/bin/x86_64-unknown-freebsd13.0-as",X_OK|R_OK) ERR#2 'No = such file or directory' >>> access("/usr/local/sbin/x86_64-unknown-freebsd13.0-as",X_OK|R_OK) = ERR#2 'No such file or directory' >>> access("/usr/local/bin/x86_64-unknown-freebsd13.0-as",X_OK|R_OK) = ERR#2 'No such file or directory' >>> = access("/usr/home/markmi/bin/x86_64-unknown-freebsd13.0-as",X_OK|R_OK) = ERR#2 'No such file or directory' >>>=20 >>> (Note: It actually explicitly tries to use the x86_64 assembler if = it >>> does not find an armv7 or a generically pathed one. The generically >>> pathed ones would normally also be x86_64 ones.) >>>=20 >>>=20 >>> Another thing of note (using aarch64 as an example): >>>=20 >>> /usr/local/aarch64-unknown-freebsd13.0/bin/as >>>=20 >>> does not appear to be someplace that clang would find as >>> but is a place devel/aarch64-binutils puts one. The change is (leading whitespace possibly not preserved): (lines 517-522 with only one line number on the line are new) 373 void ARM::relocateOne(uint8_t *Loc, RelType Type, = uint64_t Val) const { . . . 516 516 break; 517 case R_ARM_V4BX: 518 // V4BX is just a marker to indicate there's = a "bx rN" instruction at the 519 // given address. It can be used to = implement a special linker mode which 520 // rewrites ARMv4T inputs to ARMv4. Since we = support only ARMv4 input and 521 // not ARMv4 output, we can just ignore it. 522 break; 517 523 default: 518 524 error(getErrorLocation(Loc) + "unrecognized = reloc " + Twine(Type)); 519 525 } 520 526 But we have not gotten the unrecognized reloc message. Our examples did not go through ARM::relocateOne with a R_ARM_V4BX . The native poudriere build reached different code in a different routine with a different error message. The "can't create dynamic relocation" message is from lld/ELF/Relocations.cpp and its static RelExpr adjustExpr template. The amd64->armv7 cross-builds have not gotten any messages. (No direct evidence of part of its specific code path, but clearly not either of the message paths noted above.) So there are at last 3 distinct code flow paths for R_ARM_V4BX *ABS* handling in actual operation across the clang/llvm/lld variants tried, including some where the same lld source was used to build lld but different results happened. It leaves me wondering if something(s) uninitialized is(are) controlling what code ends up trying to handle the R_ARM_V4BX *ABS* . =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)