Implement APIs to get GDB/LLDB working under Darling

[LubosD]

This has super-high priority, because right now we cannot properly debug Darling or any software running underneath it.

APIs to be implemented

ptrace() operations

• PT_THUPDATE - signal delivery to inferior (after it is received over an exception port)
• PT_PTRACE_ME
• PT_SIGEXC - redirect my own signals to an exception port, only used in ptrace_me mode
• PT_DETACH
• PT_KILL
• PT_ATTACHEXC - attach and do PT_SIGEXC on child

posix_spawn() flags

• _POSIX_SPAWN_DISABLE_ASLR
  • Implement with personality(ADDR_NO_RANDOMIZE)
• POSIX_SPAWN_START_SUSPENDED
  • This should probably be implemented as a flag to mldr to suspend itself before it jumps into dyld code

Mach APIs

• task_info(TASK_DYLD_INFO)
  • Information for this needs to be delivered to LKM by mldr - it has to find a section named __DATA,__all_image_info. How exactly TBD.
• thread_get_state(GDB_X86_THREAD_STATE and GDB_X86_FLOAT_STATE)
• thread_set_state(ditto)
• thread_get_state(X86_DEBUG_STATE) + set
  • Equivalent to PTRACE_POKEUSER for u_debugreg registers - sets HW watchpoints
• task_threads()
• task_resume() + task_suspend()
• thread_resume() + thread_suspend()
• task_get_exception_ports + set
• mach_vm_region(), mach_vm_region_recurse()
  • task_t->map needs to be given a reasonable value for this
• task_for_pid()
• pid_for_task() // only used by FSF's gdb, Apple's gdb does things differently
• vm_read() + vm_write() (implement using access_process_vm())
• mach_vm_protect()

LLDB

• task_info(flavor=5) (also used by ps)
• sysctlbyname("hw.cpu64bit_capable")
• task_threads() seems to return duplicates
• sysctl({ CTL_KERN, KERN_OSVERSION })
• thread_info(THREAD_BASIC_INFO) that returns correct run_state
• sysctl({CTL_KERN, KERN_PROC, KERN_PROC_PID, nnn}) that returns kp_proc.p_flag & P_LP64 for 64-bit processes
• Implement sysctl(sysctlnametomib("sysctl.proc_cputype") + ".PID")
• Implement task_info(TASK_VM_INFO) (needs page size)
• Implement proc_pidinfo(PROC_PIDTHREADINFO) (uses pth_name)

Implementation notes

• The biggest complication is signal delivery to GDB over a Mach exception port. My current idea is to spawn a kthread upon PT_SIGEXC or PT_ATTACHEXC and trace the target process in ptrace-like manner from there.
• I think we should build Apple's GDB as part of Darling rather than point users to a repository somewhere (e.g. to avoid confusion between gdb and gdb-apple).
  • There are two different flavors of GDB for macOS: FSF and Apple. FSF's is a lot less demanding for needed APIs, but attaching to running processes is not fully implemented (it doesn't work).
• We will look into building and running LLDB once GDB works.