Taskdump cannot load symbols for binaries not in /app or /srv

[Jiri Svoboda]

If a binary that is not in /app or /srv faults and is dumped (e.g. test binary, driver, etc.), taskdump will fail to locate the binary and thus fail to load the symbols.

This is because taskdump will look at the task name and prepend /app/ and /srv/ and tries to open those paths. If the binary is located elsewhere, this will fail.

[Jiri Svoboda]

It would be nice to have a way to determine the full path of the binary corresponding to a task.

It would be useful not only for taskdump/debugging. MGI expects to find data files in paths relative to the binary. On other OSes it needs to emulate the OS binary search strategy (e.g. current dir, PATH, etc.). If we could just ask the OS, it would make it so much easier.

[Jiří Zárevúcky]

So, something akin to Linux's /proc/pid/exe. There are some considerations involved. Notably, both taskdump and the program itself need access to the binary file, but it should be possible for the file to have different paths in each process.

[Jiri Svoboda]

Yes, although /proc/pid/exe gives just the contents of the binary (I guess that would be fine for taskdump). For locating data files you need the path. The two cases (debugger and getting your own path for finding data files) are probably distinct and require a different API.

I cannot comment on different processes seeing different paths to the same file because we don't have that so it's not clear to me how that would work.

[Jiří Zárevúcky]

I guess the most common example would be chroot and related sandboxing mechanisms. But IMO, lookup of data files is a fundamentally platfrom-dependent task, and making data explicitly relative to binary path is a very weird (inflexible, nonportable) way to go about it.

[Jiri Svoboda]

No, it isn't. If your binary application is distributed by means of a simple zip file or tarball which contains the binary and data files, extracting the archive will always place your data files on the same path relative to the binary (e.g. in the same directory). Finding the files in path relative to the binary directory is better than finding them relative to CWD, because it works even if CWD != directory where we unpacked the archive.

If you wanted to have a Linux package that installs binaries in /usr/bin and data files in /usr/share, that's a completely different story and something that is decided at compile time, not at run time.

[Jiří Zárevúcky]

I see your point. I didn't consider applications distributed like that (too accustomed to package managers I guess).

By the way, on Linux, /proc/pid/exe (or /proc/self/exe) acts like a symlink, so it solves both use cases through readlink().

[Jakub Jermář]

Fixed in commit 92864752b1dfddb2a35e0b2216820f6ed1dbeb0d