[Debugger] Handle retrieving image paths for chrooted teams

[anevilyak]

Currently, LocalDebuggerInterface uses get_next_image_info() to retrieve the list of images for the targetted team. However, if the team is in a chroot, the path returned in the image information appears to have the path used inside the chroot, rather than the full filesystem path, which consequently leads to us being unable to locate the binary in question.

A few potential solutions present themselves here:

1) get_*_image_info could detect if the caller is in the same team or not, and if not, return the full path rather than the adjusted one. This may or may not be easily done depending on the inner workings of the corresponding kernel data structures (not yet investigated).

2) A new system call could be introduced that, given a team_id and a root-relative path within that team, maps it to its full filesystem path outside the chroot.

or

3) Additional calls/messages could be added to the debug API that provides similar semantics to get_*_image_info() but always returns the full path, thus leaving the former unmodified.

IMO, the third approach would probably be best, since it minimizes the risk of introducing any regressions in the more widely used standard calls, and makes it clear that the desired behavior is to return the information needed by the debugger. In any case, any such solution also needs to adjust the debug kit's image load/unload events to likewise take chroots into account if they don't already.

Thoughts/suggestions?

[korli]

image_info->name is filled up by the runtime_loader, which runs in the io_context of the current team. Switching a path to the io_context of the team which does the syscall can be expensive:

• resolve image->name to a vnode in io_context of team image (path_to_vnode),
• then resolve the vnode in io_context of another team (vnode_to_path).

I would favor another approach, that is register_image() could for chrooted images adjust the name to the kernel io context (imply that the notifications and get_next_image_info() are correct for non-chrooted processes). A chrooted get_next_image_info() call could check the io_context root to filter the absolute path (especially for paths out of the chroot).