Re: Some fixes for m68k users (incl/ for FPU emulation)

[Jason Thorpe <thorpej%me.com@localhost>]

> On Oct 30, 2026, at 2:00 PM, Romain Dolbeau <romain%dolbeau.org@localhost> wrote:
> 
> The list of patches and brief description can be found here:
> <https://github.com/MelkhiorVintageComputing/netbsd-litex-m68k/blob/litex68k/UPSTREAM.md>
> (beware: LLM-generated).

Ok, spent some time thinking about: 2.2 Kernel profiling (config -p) faults in __mcount (UP)

The shared m68k kernel Makefile machinery now automagically sets -fno-omit-frame-pointer if any of profiling, DDB, or KGDB are enabled.  Previously, this was done piecemeal in individual kernel config files, and never for when profiling was enabled.

Now I’m ruminating about the kernel frame pointer sentinel.  Contrary you what your issue says ("locore never sets %a6”), at least *some* of them so, and I am pretty sure I fixed all of them during The Great Refactor post-11.  Example in virt68k:

Lmmuenabled:
        lea     _ASM_LABEL(tmpstk),%sp  | re-load the temporary stack
        jbsr    _C_LABEL(vec_init)      | initialize the vector table

        /* phase 2 of pmap setup, returns lwp0 SP in %a0 */
        jbsr    _C_LABEL(pmap_bootstrap2)
        movl    %a0,%sp                 | now running on lwp0's stack
        movl    #0,%a6                  | terminate the stack back trace

Granted, it’s not necessarily in the *right place* (pmap_bootstrap2() is not a no-instrument function and so profiling would blow up there), but based on what mcount (look one frame up to get the previous return address, which represents “frompc”), there actually needs to be *two* dummy frames, because the final frame in the chain must have a saved-%a6 of 0, because that’s the real sentinel for stack-unwinds.  But obviously you can’t deref 0, so there has to be something else there to absorb mcount’s load.

Have I missed something?

Anyway, my solution will probably be to have a SET_KSTACK() macro in asm.h that alters its behavior on the presence of GPROF, and change all the places that fiddle with the early boot stack to use it.

Hm, I gonna have think a little more about cpu_lwp_fork() and this scenario.

-- thorpej