Date: Fri, 7 Jun 2019 03:21:44 -0700 From: Mark Millard <marklmi@yahoo.com> To: Justin Hibbits <jrh29@alumni.cwru.edu> Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: 32-bit powerpc's elf_reloc_internal has no support for R_PPC_JMP_SLOT but clang with devel/powerpc64-binutils uses such for building kernel modules Message-ID: <52B6890B-1514-424B-AC4F-B6419F8CBC79@yahoo.com> In-Reply-To: <CAHSQbTAAQMQNYcmGQttmcZsgQ9A4n6gd%2BvODttohERJEtZn9wA@mail.gmail.com> References: <FBE50EB5-F3DB-4386-8EA4-DF524B98023D@yahoo.com> <CAHSQbTAAQMQNYcmGQttmcZsgQ9A4n6gd%2BvODttohERJEtZn9wA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2019-Jun-6, at 19:41, Justin Hibbits <jrh29 at alumni.cwru.edu> =
wrote:
> On Thu, Jun 6, 2019 at 8:06 PM Mark Millard via freebsd-ppc
> <freebsd-ppc at freebsd.org> wrote:
>>=20
>>=20
>> /usr/src/sys/powerpc/powerpc/elf64_machdep.c has:
>>=20
>> static int
>> elf_reloc_internal(linker_file_t lf, Elf_Addr relocbase, const void =
*data,
>> int type, int local, elf_lookup_fn lookup)
>> {
>> . . .
>> case R_PPC_JMP_SLOT: /* function descriptor copy */
>> lookup(lf, symidx, 1, &addr);
>> #if !defined(_CALL_ELF) || _CALL_ELF =3D=3D 1
>> memcpy(where, (Elf_Addr *)addr, 3*sizeof(Elf_Addr));
>> #else
>> *where =3D addr;
>> #endif
>> __asm __volatile("dcbst 0,%0; sync" :: "r"(where) : =
"memory");
>> break;
>>=20
>> . . .
>>=20
>> But /usr/src/sys/powerpc/powerpc/elf32_machdep.c 's =
elf_reloc_internal
>> does not have any R_PPC_JMP_SLOT case in its code.
>>=20
>> Yet, from using clang as the system compiler for targeting 32-bit =
powerpc,
>> readelf -asW /boot/kernel/if_gem.ko shows the likes of:
>>=20
>> Relocation section with addend (.rela.plt):
>> r_offset r_info r_type st_value st_name + r_addend
>> 00018328 00000215 R_PPC_JMP_SLOT 00000000 if_maddr_runlock + 0
>> 00018330 00000315 R_PPC_JMP_SLOT 00000000 mii_mediachg + 0
>> 00018338 00000415 R_PPC_JMP_SLOT 00000000 m_freem + 0
>> 00018340 00000515 R_PPC_JMP_SLOT 00000000 device_get_softc + 0
>> 00018348 00000715 R_PPC_JMP_SLOT 00000000 device_set_desc + 0
>> 00018350 00000815 R_PPC_JMP_SLOT 00000000 printf + 0
>> 00018358 00000b15 R_PPC_JMP_SLOT 00000000 ether_crc32_le + 0
>> 00018360 00000e15 R_PPC_JMP_SLOT 00000000 bpf_mtap + 0
>> . . .
>>=20
>> # file /boot/kernel/if_gem.ko
>> /boot/kernel/if_gem.ko: ELF 32-bit MSB shared object, PowerPC or =
cisco 4500, version 1 (FreeBSD), dynamically linked, =
BuildID[sha1]=3D013a358835fddcd6bbb82d35a6ce36243eccb743, not stripped
>>=20
>> So, naturally, module loading such (manual or automatic)
>> is a problem for the 32-bit powerpc context.
>>=20
>> The context was head -r347549 .
>>=20
>> =3D=3D=3D
>> Mark Millard
>> marklmi at yahoo.com
>> ( dsl-only.net went
>> away in early 2018-Mar)
>=20
> Can you try this patch? Untested, just compiled. It's essentially a
> copy of the ELFv2 part of the elf64_machdep bit you posted above.
>=20
> - Justin
>=20
> diff --git a/sys/powerpc/powerpc/elf32_machdep.c
> b/sys/powerpc/powerpc/elf32_machdep.c
> index 11c14671d0b..219a61363cd 100644
> --- a/sys/powerpc/powerpc/elf32_machdep.c
> +++ b/sys/powerpc/powerpc/elf32_machdep.c
> @@ -295,6 +295,12 @@ elf_reloc_internal(linker_file_t lf, Elf_Addr
> relocbase, const void *data,
> *where =3D elf_relocaddr(lf, relocbase + addend);
> break;
>=20
> + case R_PPC_JMP_SLOT:
> + lookup(lf, symidx, 1, &addr);
> + *where =3D addr;
> + __asm __volatile("dcbst 0,%0; sync" :: "r"(where) : =
"memory");
> + break;
> +
> default:
> printf("kldload: unexpected relocation type %d\n",
> (int) rtype);
[I was away from the PowerMac, thus the delay.]
Other things that I've not figured out block use of a clang
based kernel for my oontext. So this was a test of a
gcc-4.2.1-based debug kernel loading a clang built
filemon.ko (also from a debug build). This was done via the
loader prompt:
Ok unload
Ok load /boot/kerdbg/kernel
Ok boot
At the time /boot/kernel/* was from a clang-based build.
The above context still uses /boot/kernel/ for finding
modules, not /boot/kerdbg/ .
Attempting kldload filemon.ko after booting (as an example
of something with R_PPC_JMP_SLOT involved) caused a system
crash via an illegal instruction: (typed from a picture of
the screen)
exception =3D 0x700 (program)
srr0 =3D 0xdd3a28b0
srr1 =3D 0x89032
current msr=3D 0x9032
ls =3D 0xdd38fcd8
frame=3D 0x24f23a0
pid =3D 1247, comm =3D kldload
. . .
kdb_backtrace+0x5c
vpanic+0x1f8
panic+0x54
trap_fatal+0x238
trap+0xca8
powerpc_interrupt+0x248
kernel PGM trap by _GLOBAL_OFFSET_TABLE+0x13c: srr1=3D0x89032
r1=3D0xe1d3e5d0 cr=3D0x8000f044 xer=3D0x2000000 ctr=3D0xdd38fcfc =
frame=3D0xe1d3e518
0xca2af4
module_register_init+0xb4
linker_load_module_+0x8dc
kern_kldload+0x138
sys_kldload+0x80
trap+0x54c
powerpc_interrupt+0x248
user SC trap by 0x418a44f8: srr1=3D0xf032
r1=3D0xffffd750 cr=3D0x44222800 xer=3D0 ctr=3D0x418a44f0 =
frame=3D0xe1d3ea48
A better test would be not from my experimental environment,
say matching some artifact build, other than haivng your patch.
But if I do that it will not be tonight/this-morning. I do not
expect a different result.
=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?52B6890B-1514-424B-AC4F-B6419F8CBC79>