Date: Thu, 23 Jan 2020 18:32:58 -0800 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: powerpc64 ELFv2 ABI and use of r2 for TOC Pointer Relative Accesses vs. FreeBSD (and gcc) use of other registers instead Message-ID: <95B7EE95-26B8-4D02-A934-6F3F6EAF9C64@yahoo.com> References: <95B7EE95-26B8-4D02-A934-6F3F6EAF9C64.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[I experiment with trying both system-clang with devel/binutils@powerpc64 and trying devel/freebsd-gcc9@powerpc64 with devel/binutils@powerpc64 for buildworld buildkernel .] In searching around about tool complaints that got/toc optimization is not supported for various instruction encodings that are used, I ran into: = http://openpowerfoundation.org/wp-content/uploads/resources/leabi/content/= dbdoclet.50655241_66700.html QUOTE Compilers may generate two-instruction medium code model references (or, if selected, short displacement one-instruction references) for all data items that are in the TOC for the object file being compiled. Such references are relative to the TOC pointer register, r2. (The linker may optimize two-instruction forms to one instruction forms, replacing a first instruction of the two instruction form with a nop and rewriting the second instruction. Consequently, the TOC pointer must be live during the first and second instruction of a two-instruction reference.) END QUOTE And into: = http://openpowerfoundation.org/wp-content/uploads/resources/leabi/content/= ch03s06s03.html and its statement: QUOTE Compilers and programmers must ensure that r2 is live at the actual data access point associated with extended displacement addressing. END QUOTE This last was in a context about: QUOTE Assemblers and linkers may optimize TOC reference code that consists of = two instructions with equivalent code when offset@ha is 0. TOC reference code: addis rt, r2, offset@ha lwz rt, offset@l(rt) Equivalent code: NOP lwz rt, offset(r2) END QUOTE There was also: QUOTE The static linker must modify a nop instruction after a bl function call to restore the TOC pointer in r2 from 24(r1) when an external symbol that may use the TOC may be called, as in Section 2.3.6, =E2=80=9CFunction Calls=E2=80=9D. Object files must contain a nop slot = after a bl instruction to an external symbol. END QUOTE at: = http://openpowerfoundation.org/wp-content/uploads/resources/leabi/content/= dbdoclet.50655241_69294.html These probably explains why I see a complaint for the addis instruction in: dbtrap: /* Write the trap vector to SPRG3 by computing LR & 0xff00 */ mflr %r1 andi. %r1,%r1,0xff00 mtsprg3 %r1 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) The tools involved expect: addis ...,r2,... for such a context instead. Apparently, lack of r2 use also explains the long list of such messages for zfs.ko.full when I'm building via devel/freebsd-gcc9@powerpc64 : the code generated might not be sticking to use of r2 in that spot for addis. (So far, I've yet to look at the detail for zfs.) =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?95B7EE95-26B8-4D02-A934-6F3F6EAF9C64>