Date: Mon, 6 Jan 2020 23:18:48 -0800 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: Involving devel/binutils@powerpc64 in buildworld buildkernel : got/toc optimization is not supported for addis %r1,%r1,TOC_REF(trapstk)@ha (and the like) Message-ID: <FB7DEA40-422F-4975-B8BE-6DB65CE88AF6@yahoo.com> In-Reply-To: <00DFB84D-D694-4BCA-A15F-5098F0320FA9@yahoo.com> References: <00DFB84D-D694-4BCA-A15F-5098F0320FA9@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Jan-6, at 22:52, Mark Millard <marklmi at yahoo.com> wrote: > The following is based on what I noticed while > working on updating to head -r356426 , including > building multiple ways (discovering what fails > to build and such). >=20 > I was looking at messages and noticed that there > were messages such as: >=20 > --- kernel.full --- > locore.o: in function `dbtrap': > /usr/src/sys/powerpc/aim/trap_subr64.S:905:(.text+0xa68): got/toc = optimization is not supported for 0x3c210000 instruction >=20 > That is the addis instruction in: >=20 > dbtrap: > /* Write the trap vector to SPRG3 by computing LR & 0xff00 */ > mflr %r1 > andi. %r1,%r1,0xff00 > mtsprg3 %r1 >=20 > GET_TOCBASE(%r1) /* get new SP */ > addis %r1,%r1,TOC_REF(trapstk)@ha > ld %r1,TOC_REF(trapstk)@l(%r1) > addi %r1,%r1,(TRAPSTKSZ-48) >=20 > (based on line number). >=20 > This was for system-clang and devel/binutils@powerpc64 > being used to do the build. >=20 > But it also happened for devel/freebsd-gcc9@powerpc64 > and devel/binutils@powerpc64 bing used to do the > build: >=20 > --- kernel.full --- > locore.o: in function `dbtrap': > /usr/src/sys/powerpc/aim/trap_subr64.S:905:(.text+0xa68): got/toc = optimization is not supported for 0x3c210000 instruction >=20 > (Same instruction, same message.) >=20 >=20 > There are lots of similar messages for other instruction > encodings for zfs.ko.full --but only for the > devel/freebsd-gcc9@powerpc64 and devel/binutils@powerpc64 > combination: >=20 > --- zfs.ko.full --- > zfs.kld: in function `acl_trivial_create': > = /usr/src/sys/cddl/contrib/opensolaris/common/acl/acl_common.c:1646:(.text+= 0x568): got/toc optimization is not supported for 0x3d9e0000 instruction > zfs.kld: in function `cacl_malloc': > = /usr/src/sys/cddl/contrib/opensolaris/common/acl/acl_common.c:243:(.text+0= x5e0): got/toc optimization is not supported for 0x3d9e0000 instruction > zfs.kld: in function `ace_trivial': > = /usr/src/sys/cddl/contrib/opensolaris/common/acl/acl_common.c:1764:(.text+= 0x990): got/toc optimization is not supported for 0x3d9e0000 instruction > zfs.kld: in function `avl_nearest': > . . . >=20 > The list for zfs.ko.full is large. >=20 > Overall there are examples of each of: >=20 > got/toc optimization is not supported for 0x3c210000 instruction > got/toc optimization is not supported for 0x3c9e0000 instruction > got/toc optimization is not supported for 0x3cbe0000 instruction > got/toc optimization is not supported for 0x3cde0000 instruction > got/toc optimization is not supported for 0x3cfe0000 instruction > got/toc optimization is not supported for 0x3d1e0000 instruction > got/toc optimization is not supported for 0x3d3e0000 instruction > got/toc optimization is not supported for 0x3d5e0000 instruction > got/toc optimization is not supported for 0x3d9e0000 instruction > got/toc optimization is not supported for 0x3dde0000 instruction > got/toc optimization is not supported for 0x3dfe0000 instruction > got/toc optimization is not supported for 0x3e1e0000 instruction > got/toc optimization is not supported for 0x3e3e0000 instruction > got/toc optimization is not supported for 0x3e5e0000 instruction > got/toc optimization is not supported for 0x3e7e0000 instruction > got/toc optimization is not supported for 0x3e9e0000 instruction > got/toc optimization is not supported for 0x3ebe0000 instruction > got/toc optimization is not supported for 0x3ede0000 instruction > got/toc optimization is not supported for 0x3efe0000 instruction > got/toc optimization is not supported for 0x3f1e0000 instruction > got/toc optimization is not supported for 0x3f3e0000 instruction > got/toc optimization is not supported for 0x3f5e0000 instruction > got/toc optimization is not supported for 0x3f7e0000 instruction > got/toc optimization is not supported for 0x3f9e0000 instruction > got/toc optimization is not supported for 0x3fbe0000 instruction >=20 > I'm not sure of the implications, but I figured that the > information might be of use at some point. Looking around on the web, it looks like the relevant code in gnu's ld might be from this 2019-Aug-19 material: + enum {no_check, check_lo, check_ha} insn_check; =20 r_type =3D ELF64_R_TYPE (rel->r_info); + switch (r_type) + { + default: + insn_check =3D no_check; + break; + + case R_PPC64_PLT16_HA: + case R_PPC64_GOT_TLSLD16_HA: + case R_PPC64_GOT_TLSGD16_HA: + case R_PPC64_GOT_TPREL16_HA: + case R_PPC64_GOT_DTPREL16_HA: + case R_PPC64_GOT16_HA: + case R_PPC64_TOC16_HA: + insn_check =3D check_ha; + break; + + case R_PPC64_PLT16_LO: + case R_PPC64_PLT16_LO_DS: + case R_PPC64_GOT_TLSLD16_LO: + case R_PPC64_GOT_TLSGD16_LO: + case R_PPC64_GOT_TPREL16_LO_DS: + case R_PPC64_GOT_DTPREL16_LO_DS: + case R_PPC64_GOT16_LO: + case R_PPC64_GOT16_LO_DS: + case R_PPC64_TOC16_LO: + case R_PPC64_TOC16_LO_DS: + insn_check =3D check_lo; + break; + } + + if (insn_check !=3D no_check) + { + bfd_vma off =3D rel->r_offset & ~3; + + if (!bfd_get_section_contents (ibfd, sec, buf, off, = 4)) + goto got_error_ret; + + insn =3D bfd_get_32 (ibfd, buf); + if (insn_check =3D=3D check_lo + ? !ok_lo_toc_insn (insn, r_type) + : ((insn & ((0x3f << 26) | 0x1f << 16)) + !=3D ((15u << 26) | (2 << 16)) /* addis = rt,2,imm */)) + { + char str[12]; + + ppc64_elf_tdata (ibfd)->unexpected_toc_insn =3D 1; + sprintf (str, "%#08x", insn); + info->callbacks->einfo + /* xgettext:c-format */ + (_("%H: got/toc optimization is not supported = for" + " %s instruction\n"), + ibfd, sec, rel->r_offset & ~3, str); + continue; + } + } =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FB7DEA40-422F-4975-B8BE-6DB65CE88AF6>