AFAIK gdb does not use fancy information like file-mapping stuff. NT_FILE is probably hard to support on the Hurd, since we don't have a way to go backwards from a memory object port to a file (let alone a file name).
All GDB needs is to know where the PIE was loaded, so it can find the DT_DEBUG and bootstrap the link_map list from there. On Linux, NT_AUXV in a core file has AT_ENTRY and from that and the ELF file, you can figure out where the PIE was loaded. In a live process, you read the same info from /proc/$pid/auxv. On the Hurd, we don't really have auxv at all. But to simplify things with GDB, we could have our core dumps include an NT_AUXV containing just an AT_ENTRY value synthesized by other means. Off hand I don't recall anything we store that can be used to compute such a value. Probably the right thing is to have the proc server keep that state like it does arg_locations, with the exec server writing it and the debugger and core-writer reading it.