An update from me: /hurd/startup starts up (which means that exec is now working -- how cool is that!) and then spawns auth and proc. But then proc task_terminate's itself (= exists with some error, likely), seemingly somewhere early, maybe even during ld.so startup -- before it gets a chance to open the console and actually print the error. Why/where exactly, I have not yet been able to figure out.
It is getting much harder to debug things now that there are several tasks involved. Dynamic linking also adds its share of complexity, since I don't know where DSOs get loaded, and I just have to *guess* which function I'm looking at, and if I guess correctly I can then calculate the load address of the DSO's .text that I can then give to gdb's add-symbol-file. Moreover, the debuginfo package for the 'hurd' Debian package seemingly hasn't been rebuilt, so I don't have any debug symbols either. If anyone has any tips for debugging early boot, please share! Or in general: how do I properly debug a dynamically linked program which is loaded, in user mode, in QEMU, if I'm attaching GDB to the whole machine (qemu's gdbstub) and not just the task? When GDB is attached to a task, the dynamic linker lets GDB know about loaded DSOs through _r_debug; but this is not the case here. Speaking of which, how does GDB even find _r_debug, normally? glibc has a comment talking about DT_DEBUG in the executable's .dynamic section; but surely to access that GDB needs to know where the executable is mapped first? Does it use AT_ENTRY from auxval, i.e. proc_get_entry ()? Sergey