Re: [PATCH 00/41] The x86_64 port

[Sergey Bugaev]

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