BUG: /proc/self/exe reports relative paths, should always return absolute paths?

[Svante Signell]

Hi,

When working on porting gccgo to gcc-7, I found out that many test failures are
due to a bug in Hurd's implementation of /proc/self/exe (and /proc/<pid>/exe):
The path returned should always be absolute, not relative. 
Adding print statements to libbacktrace/posix.c shows the problem:

GNU/Linux:
./build/gotools/go
linkname = /home/srs/Hurd/DEBs/linux_DEBs/gcc-7/gcc-7-7.2.0-4/build/gotools/go
<help text displayed>

$PWD/build/gotools/go
<same as above>

GNU/Hurd:
./build/gotools/go
linkname = ./build/gotools/go
fatal error: libbacktrace could not find executable to open

$PWD/build/gotools/go
linkname = /home/srs/DEBs/gcc-7/gcc-7-7.2.0-3.1/build/gotools/go
<help text displayed>

The following attached programs verifies this issue.
Both Linux programs are tested on amd64 and i386. 

1) test_readlink.c: 

GNU/Linux:
./test_readlink /proc/self/exe
bufsize = 4096
'/proc/self/exe' points to '/home/srs/Hurd/DEBs/test_cases/test_readlink'
$PWD/test_readlink /proc/self/exe
<same as above>
Here /proc reports a zero st_size from the lstat call. Obviously Hurd does not.
Perhaps not a big deal?

GNU/Hurd:
./test_readlink /proc/self/exe
bufsize = 16
'/proc/self/exe' points to './test_readlink'

$PWD/test_readlink /proc/self/exe
bufsize = 40
'/proc/self/exe' points to '/home/srs/DEBs/test_cases/test_readlink'

2) test_sighandler.c:

GNU/Linux:
./test_sighandler
Got signal 11, faulty address is 0xdeadbeef, from 5597bd471de0
Executable name = '/home/srs/Hurd/DEBs/test_cases/test_sighandler�', len = 47
[bt] Execution path:
[bt] ./test_sighandler(func_b+0x11) [0x5597bd471de0]
[bt] ./test_sighandler(func_b+0x11) [0x5597bd471de0]
[bt] ./test_sighandler(main+0x6a) [0x5597bd471e54]
[bt] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f1cdc8d12b1]
[bt] ./test_sighandler(_start+0x2a) [0x5597bd471ada]

GNU/Hurd:
./test_sighandler
Got signal 4
Executable name = './test_sighandler

', len = 21
[bt] Execution path:
[bt] ./test_sighandler(func_b+0x10) [0x8048986]
[bt] ./test_sighandler(main+0x6f) [0x80489ff]
[bt] /lib/i386-gnu/libc.so.0.3(__libc_start_main+0xaa) [0x10b6eea]

This is another bug in the backtrace. hex2dec('deadbeef')/1024^3 = 3.4794 GiB
Even if the address is outside the gnumach range, the program should not fail
with a SIGILL. Or?

Changing 0xdeadbeef to 0xbeadbeef gives:

./test_sighandler
Got signal 11, faulty address is 0xbeadbeef, from 8048986
Executable name = './test_sighandler

', len = 21
[bt] Execution path:
[bt] ./test_sighandler(func_b+0x10) [0x8048986]
[bt] ./test_sighandler(main+0x5c) [0x80489ec]
[bt] /lib/i386-gnu/libc.so.0.3(__libc_start_main+0xaa) [0x10b6eea]

test_sighandler.c
Description: Text Data

test_readlink.c
Description: Text Data