The TLS offset is a property of the process ABI.

[brooks]

Summary

Move to a per-proc TLS offset rather than incorrectly keying off the
presense of freebsd32 compability in the kernel.

Obtained from: CheriBSD
Sponsored by: DARPA, AFRL

[adrian]

can someone test this on a mips64 platform? I'm outta time atm :(

[sbruno]

Building this nowish, I'll qemu a thing as I don't have real h/w

[sbruno]

This seems to crash immediately on startup:

 % qemu-system-mips64 -m 512M -M malta -kernel /var/tmp/mips.mips64/home/sbruno/fbsd_head/sys/MALTA64/kernel -hda ./mips64_clang.img -nographic                               
WARNING: Image format was not specified for './mips64_clang.img' and probing guessed raw.
         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
         Specify the 'raw' format explicitly to remove the restrictions.
entry: platform_start()
cmd line: /var/tmp/mips.mips64/home/sbruno/fbsd_head/sys/MALTA64/kernel  
envp:
        memsize = 268435456
        ememsize = 536870912
        modetty0 = 38400n8r
memsize = 268435456 (0x10000000)
ememsize = 536870912
panic: remove_userlocal_code: Unable to patch cpu_switch().
Uptime: 1s

[brooks]

Bah. I've clearly botched a part of the merge.

The issue is going to be a difference between the machine code generated from the bits that changed in mips/mips/swtch.S and the attempt to fix it up in sys/mips/mips/cpu.c. I'll see about setting up a test environment for regular mips64.

[brooks]

@sbruno Is your build with gcc or clang? I get to mount root in qemu with this patch applied.

[brooks]

I do wonder if a better approach wouldn't be to add a global label to the beginning of the code we want to short circuit and just replace the first instruction blindly rather than pattern matching instructions in cpu_switch()

[sbruno]

In D7843#163578, @brooks wrote:

@sbruno Is your build with gcc or clang? I get to mount root in qemu with this patch applied.

This was against head building with gcc.

[brooks]

Ah, I'm seeing this with qemu-system-mips64, but not with qemu-system-cheri.

[sbruno]

Just retested to make sure I wasn't daft.

I rm -rf'd everything in my buildobj dir, did a clean world/kernel:

make -s -j16 buildworld TARGET=mips TARGET_ARCH=mips64
make -s -j16 buildkernel TARGET=mips TARGET_ARCH=mips64 KERNCONF=MALTA64

Installed to a temp dir and did a makefs to get a root device for qemu:
make -s installworld distribution TARGET=mips TARGET_ARCH=mips64 DESTDIR=/home/sbruno/testgccmips64
makefs -M 1g -B be mips64_gcc.img /home/sbruno/testgccmips64

Booted qemu-devel with:
qemu-system-mips64 -m 512M -M malta -kernel /var/tmp/mips.mips64/home/sbruno/fbsd_head/sys/MALTA64/kernel -hda ./mips64_gcc.img -nographic

With this review applied, reported crashes persist.

I reverted back to stock HEAD, and did a -DNO_CLEAN rebuild, system booted just fine.

[brooks]

It looks like the _ADDU_V0_T0_T1 macro is wrong. It's producing b58d1000, but the generated code is:

       PTR_ADDU v0, t0, t1
ffffffff8055c468:       018d102d        daddu   v0,t0,t1

[brooks]

• Correct the encoding of (D)ADDU instructions.

[brooks]

Now this works for me with qemu-system-mips64.

[sbruno]

Seems happy to me now. Thanks for the updates.

[sbruno]

For the record, I *did* test mips32 as well and all seemed to be good under MALTA emulation via qemu.

[brooks]

Thanks for all the testing @sbruno !