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

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:
>> 
>> 
>> /usr/src/sys/powerpc/powerpc/elf64_machdep.c has:
>> 
>> 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 == 1
>>                memcpy(where, (Elf_Addr *)addr, 3*sizeof(Elf_Addr));
>> #else
>>                *where = addr;
>> #endif
>>                __asm __volatile("dcbst 0,%0; sync" :: "r"(where) : "memory");
>>                break;
>> 
>> . . .
>> 
>> 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.
>> 
>> Yet, from using clang as the system compiler for targeting 32-bit powerpc,
>> readelf -asW /boot/kernel/if_gem.ko shows the likes of:
>> 
>> 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
>> . . .
>> 
>> # 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]=013a358835fddcd6bbb82d35a6ce36243eccb743, not stripped
>> 
>> So, naturally, module loading such (manual or automatic)
>> is a problem for the 32-bit powerpc context.
>> 
>> The context was head -r347549 .
>> 
>> ===
>> Mark Millard
>> marklmi at yahoo.com
>> ( dsl-only.net went
>> away in early 2018-Mar)
> 
> 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.
> 
> - Justin
> 
> 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 = elf_relocaddr(lf, relocbase + addend);
>                break;
> 
> +       case R_PPC_JMP_SLOT:
> +               lookup(lf, symidx, 1, &addr);
> +               *where = 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 = 0x700 (program)
srr0 = 0xdd3a28b0
srr1 = 0x89032
current msr= 0x9032
ls = 0xdd38fcd8
frame= 0x24f23a0
pid = 1247, comm = 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=0x89032
r1=0xe1d3e5d0 cr=0x8000f044 xer=0x2000000 ctr=0xdd38fcfc frame=0xe1d3e518
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=0xf032
r1=0xffffd750 cr=0x44222800 xer=0 ctr=0x418a44f0 frame=0xe1d3ea48


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.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[email protected]"