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>