Darling: Mach-O loading in kernel

[LubosD]

In relation to #304 (getting LLDB working under Darling), we need to move Mach-O loading to the kernel.

This has several benefits:

• XNU task will be created at the same time as the Linux process (this is the main motivation - #304).
• Faster loading, because mldr will no longer be involved.
• Makes things a bit cleaner.

And disadvantages:

• We'll have to redo our approach to calling ELF APIs.

Steps - Mach-O

• [x] Load Mach-Os in kernel. See if we can adapt Wenqi's code for this.
• [x] Move commpage generation into the kernel.
• [x] Hide /dev/mach from userspace. Open devmach fd inside the kernel Mach-O loader (and make it O_CLOEXEC).
• [x] Provide information to dyld_info in the XNU task (needed for debuggers).
• [x] Remove /dev/mach opening from libsystem_kernel. Maybe we could get the fd number via apple[] args to entry point?

Steps - ELF

• [x] Introduce a library for loading ELF files...:
• [x] Create a simple ELF loader (similar to the kernel ELF loader - no dynamic library loading).
• [x] Create an ELF stub that gets jumped into by the loader (dynamic loader) and returns control back into Mach-O (while passing along fnptrs to dlopen() and friends). We could pass a function pointer via argv[] and this function would longjmp() back in order to rewind the stack.
• [x] Modify libsystem_kernel to access our ELF wrapper for bsdthread_* syscall implementation.

More Ideas

• [x] Provide commpage contents as a mmap from the devmach fd. The devmach fd would then be closed before jumping to the entry point. This way we'd avoid polluting the fd table, but still learn about process termination (the memory mapping destruction would close the struct file*).
• [x] Register an IDT entry (e.g. 0x83) for using for LKM calls instead of ioctl() and do int 0x83 to make LKM calls.

[LubosD]

Interrupt handler impl

TODO: is some register saving needed?

call lkmcall
swapgs
iretq

Interrupt handler installation

void isr_install(void)
{
        struct desc_ptr newidtr;
        gate_desc *oldidt, *newidt;
        unsigned long idtpage;
        void* isr = NULL; // TODO: fill in func ptr here

        struct desc_ptr idtreg;

        store_idt(&idtreg);
        oldidt = (gate_desc *)idtreg.address;

        idtpage =__get_free_page(GFP_KERNEL);
        if(!idtpage)
                return;

        newidtr.address = idtpage;
        newidtr.size = idtreg.size;
        newidt = (gate_desc *)newidtr.address;

        memcpy(newidt, oldidt, idtreg.size);

        pack_gate(&newidt[0x83], GATE_INTERRUPT, (unsigned long)isr, 0x3, 0, __KERNEL_CS);

        load_idt((void *)&newidtr);
        smp_call_function((smp_call_func_t) load_idt, &newidtr, 1);
}

[LubosD]

LLDB observations:

TaskPortForProcessID:

• Called after LLDB receives SIGTRAP for the exec() that just happened. task_t should be ready when this signal is delivered. (Should already be the case, because this is supposed to be generated once the new process is ready to run.)

PosixSpawnChildForPTraceDebugging:

• Uses ptrace(PT_ATTACHEXC) - maybe this should wait until attachable?
• -> We should probably block the RT signals we use for ptrace() impl until the child process is ready to handle it.

[bugaevc]

:tada: