Could not open `target:/lib64/libseccomp.so.2' as an executable file: No such file or directory

I'm not sure why gdb(?) tries to open this but for me it's in /usr/lib64, not /lib64.  Is virtiofsd maybe run inside some container/namespace that confuses gdb?

At least virtiofsd supports sandboxes/chroots:

% /usr/libexec/virtiofsd --help
...
    -o sandbox=namespace|chroot
                               sandboxing mode:
                               - namespace: mount, pid, and net
                                 namespaces with pivot_root(2)
                                 into shared directory
                               - chroot: chroot(2) into shared
                                 directory (use in containers)
                               default: namespace
...

(in particular: note the default!).

Attaching to running processes requires some heuristics in gdb in order to find
the correct files that the process has loaded, and in this case it seems that
those heuristics fail.  In some cases those heuristics can't find out the correct
rootdir at all, think about a process that loads "/foo/bar.so", then chroots
into "/X", loads "/a.so", then chroots into "/Y", then loads "/b.so".  The process
image of the process will say it loaded "/b.so" and "/a.so", but there's no
way to know that the latter was "/X/a.so", not "/X/Y/a.so" (should that exist).

So, it might be that gdb's heuristics could be made to work in this scenario,
until then you need to help gdb, e.g. by setting gdb's sysroot to "/":

(gdb) show sysroot
The current system root is "target:".
(gdb) set sysroot /

Giving to Tom for investigating if something could be improved on gdb's side
for this case.  For that, Dario: please provide a snippet of how you (or qemu)
starts virtiofsd, I didn't manage to start it myself to see your example break.

(In reply to Richard Biener from comment #1)
> Could not open `target:/lib64/libseccomp.so.2' as an executable file: No
> such file or directory
> 
> I'm not sure why gdb(?) tries to open this but for me it's in /usr/lib64,
> not /lib64.  
>
It's in both places, here in my system:

> # ls -l /usr/lib64/libseccomp.so.2
> lrwxrwxrwx 1 root root 19 Feb 19 22:52 /usr/lib64/libseccomp.so.2 -> libseccomp.so.2.5.3
> # ls -l /lib64/libseccomp.so.2
> lrwxrwxrwx 1 root root 19 Feb 19 22:52 /lib64/libseccomp.so.2 -> libseccomp.so.2.5.3

Maybe due to this?

> # ls -l /|grep lib64
> lrwxrwxrwx   1 root root    9 Mar  9 20:00 lib64 -> usr/lib64

> Is virtiofsd maybe run inside some container/namespace that
> confuses gdb?
>
cgroups are involved for sure, due to how libvirt configures things:

> # pstree -pa |grep virtiofs
>   |-virtiofsd,8045 --fd=34 -o source=/home/test/share -d
>   |   |-virtiofsd,8072 --fd=34 -o source=/home/test/share -d
>   |   |   |-{virtiofsd},8073
>   |   |   |-{virtiofsd},8395
>   |   |   `-{virtiofsd},8396
>   |   `-{virtiofsd},8048

# cat /proc/8045/task/*/cgroup
0::/machine.slice/machine-qemu\x2d1\x2dopensusetumbleweed\x2djeos.scope/libvirt/emulator
0::/machine.slice/machine-qemu\x2d1\x2dopensusetumbleweed\x2djeos.scope/libvirt/emulator

# cat /proc/8072/task/*/cgroup
0::/machine.slice/machine-qemu\x2d1\x2dopensusetumbleweed\x2djeos.scope/libvirt/emulator
0::/machine.slice/machine-qemu\x2d1\x2dopensusetumbleweed\x2djeos.scope/libvirt/emulator
0::/machine.slice/machine-qemu\x2d1\x2dopensusetumbleweed\x2djeos.scope/libvirt/emulator
0::/machine.slice/machine-qemu\x2d1\x2dopensusetumbleweed\x2djeos.scope/libvirt/emulator

Namespace wise, can you tell what kind of information I can share, to help you understand the situation? For now:

> # readlink /proc/8045/task/*/ns/* | sort -u
> cgroup:[4026531835]
> ipc:[4026531839]
> mnt:[4026531840]
> mnt:[4026532396]
> net:[4026531992]
> net:[4026532399]
> pid:[4026531836]
> pid:[4026532397]
> time:[4026531834]
> user:[4026531837]
> uts:[4026531838]

> # readlink /proc/8072/task/*/ns/* | sort -u
> cgroup:[4026531835]
> ipc:[4026531839]
> mnt:[4026532396]
> net:[4026532399]
> pid:[4026532397]
> time:[4026531834]
> user:[4026531837]
> uts:[4026531838]

(In reply to Michael Matz from comment #2)
> So, it might be that gdb's heuristics could be made to work in this scenario,
> until then you need to help gdb, e.g. by setting gdb's sysroot to "/":
> 
> (gdb) show sysroot
> The current system root is "target:".
> (gdb) set sysroot /
> 
> Giving to Tom for investigating if something could be improved on gdb's side
> for this case.  For that, Dario: please provide a snippet of how you (or
> qemu)
> starts virtiofsd, I didn't manage to start it myself to see your example
> break.
>
In theory, with something like this should work:

> # /usr/libexec/virtiofsd --socket-path=/tmp/vsock -o source=/home/test/share -o cache=always
> # qemu-system-x86_64 -M pc -cpu host --enable-kvm -smp 2 -m 4G \
>   -object memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on -numa node,memdev=mem \
>   -chardev socket,id=char0,path=/tmp/vsock -device vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=myfs \
>   -chardev stdio,mux=on,id=mon -mon chardev=mon,mode=readline -device virtio-serial-pci -device virtconsole,chardev=mon \
>   -vga none -display none -drive if=virtio,file=/home/test/openSUSE-Tumbleweed-JeOS.x86_64-kvm-and-xen.qcow2

It's different than my usecase as, e.g., libvirt is not there creating the cgroups etc.

But I still see the problem if I try to attach with gdb.

Instead, in order to replicate exactly what I'm using, I guess the best way is to create a simple VM, e.g., with virt-manager, and then add a virtiofs shared filesystem, either from the GUI or adding this to the XML:

> <filesystem type="mount" accessmode="passthrough">
>   <driver type="virtiofs"/>
>   <source dir="/home/test/share"/>
>   <target dir="host_share"/>
> </filesystem>

Let me know if this helps.