Hallo Alexander,
Returning to my question, could I use posix open(«/test-go») to open my binary from which I run executable, if I have the following code in run file: […]
Yes, using 'open()' is the way to go. As libbacktrace hardcodes a few options you could piggy-back on one of them. I picked the '/proc/self/exe' option:
! <start name="test-go" caps="250"> ! <resource name="RAM" quantum="12M"/> ! <config verbose="yes" ld_verbose="yes"> ! <vfs> ! <dir name="dev"> <log/> </dir> ! ! <dir name="proc"> ! <dir name="self"> ! <rom name="exe" label="test-go"/> ! </dir> ! </dir> ! </vfs> ! <libc stdout="/dev/log" stderr="/dev/log"/> ! </config> ! </start>
With this VFS configuration in place libbacktrace opens the binary successfully. However, you will be greeted with the by now infamous deadlock ahead error message when using '-smp 2':
! [init -> test-go] Error: deadlock ahead, mutex=0x164040, return ip=0xf3383
The mutex in question is the 'Linker::mutex()' object. Again this is due to the fact that as side-effect of 'dl_iterate_phdr' a jump-slot relocation for 'mknod' takes place (*). Why that is I have not checked.
Now we are not entirely sure if taking the mutex in 'dl_iterate_phdr' is strictly necessary - that is something we have to investigate. Removing the mutex allows the 'go_app' to run through. So you are free to do the same. But to be clear, we do not know if this leads to other regressions. We are going to look into that.
(*) You can instrument that by applying the patch I attached that makes the linker verbose and shows you the object and index for the relocation:
! […] ! [init -> test-go] LD: SLOT libc.lib.so 0x20c ! [init -> test-go] LD: SLOT binary 0xe ! [init -> test-go] Error: deadlock ahead, mutex=0x164040, return ip=0xf3383
With this information you can check to which symbol the index belongs to:
$ readelf --dyn-syms test-go|grep '<14:' 14: 0000000000000000 0 FUNC GLOBAL DEFAULT UND mknod
Regards Josef