记录bug
-bash: ./app: no such file or directory
Bug产生背景：项目里用g++编译产生*.o，然后再用动态链接得到可执行文件app，执行时发现无法运行，报错信息非常奇怪，是-bash: ./app: no such file or directory。看到这个报错我的第一反应当然是检查文件是否存在，ls指令告诉我文件的确存在。
# ls -lh | grep app
-rwxr-xr-x 1 root root 115K Aug 25 17:34 app
遇到没有见过的bug，首先要做的当然是搜索有没有类似的问题。用关键词"bash", "no such file or directory"的确搜索到了很多post，提示有可能是文件的位数和系统位数不一致，比如32的文件尝试在64位系统上执行，就会产生这个错误。file指令告诉我文件是64位的，然后uname指令又告诉我系统也是64位的。因此这个原因被排除了。
# file app
app: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld64.so.1,
for GNU/Linux 2.6.32, BuildID[sha1]=01185822dd63c4dd6da6c6673ae7bdc36f8cac43, not stripped
# uname -a
Linux vca_node_00 4.14.20-1.2.3.26.vca #1 SMP Wed Nov 28 17:11:04 CET 2018 x86_64 x86_64 x86_64 GNU/Linux
更进一步的搜索结果暗示bug可能是缺失的系统库引起的，用ldd命令检查发现系统库一切正常。
# ldd app
linux-vdso.so.1 => (0x00007ffe1ba94000)
libsgx_urts.so => /usr/lib/x86_64-linux-gnu/libsgx_urts.so (0x00007f01fd02b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f01fce0e000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f01fca8c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f01fc6c2000)
libsgx_enclave_common.so.1 => /usr/lib/x86_64-linux-gnu/libsgx_enclave_common.so.1 (0x00007f01fc4b2000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f01fc2ae000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f01fc098000)
/lib/ld64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x00007f01fd26e000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f01fbd8f000)
libsgx_uae_service.so => /usr/lib/x86_64-linux-gnu/libsgx_uae_service.so (0x00007f01fbb10000)
libprotobuf.so.9 => /usr/lib/x86_64-linux-gnu/libprotobuf.so.9 (0x00007f01fb7f2000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f01fb5d8000)
感觉debug陷入了走投无路的阶段了。直接解析源码，发现program sections一切正常。
# readelf -l app
Elf file type is EXEC (Executable file)
Entry point 0x4017d0
There are 8 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000400040 0x0000000000400040
0x00000000000001c0 0x00000000000001c0 R E 8
INTERP 0x0000000000000200 0x0000000000400200 0x0000000000400200
0x000000000000000f 0x000000000000000f R 1
[Requesting program interpreter: /lib/ld64.so.1]
LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
0x000000000000a3c8 0x000000000000a3c8 R E 200000
LOAD 0x000000000000ac80 0x000000000060ac80 0x000000000060ac80
0x0000000000000718 0x0000000000000998 RW 200000
DYNAMIC 0x000000000000add8 0x000000000060add8 0x000000000060add8
0x0000000000000200 0x0000000000000200 RW 8
NOTE 0x0000000000000210 0x0000000000400210 0x0000000000400210
0x0000000000000044 0x0000000000000044 R 4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 10
GNU_RELRO 0x000000000000ac80 0x000000000060ac80 0x000000000060ac80
0x0000000000000380 0x0000000000000380 R 1
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .plt.got .text .fini .rodata .eh_frame .gcc_except_table
03 .init_array .fini_array .jcr .data.rel.ro .dynamic .got .got.plt .data .bss
04 .dynamic
05 .note.ABI-tag .note.gnu.build-id
06
07 .init_array .fini_array .jcr .data.rel.ro .dynamic .got
但program headers中有一行引人注意：[Requesting program interpreter: /lib/ld64.so.1]。结合关键词ld64.so.1，新的搜索结果显示尽管ldd告诉我们系统知道了这个库的位置，但在/lib64文件夹下的库在程序装载时无法使用。这个库是一个关键的动态链接库，失去这个库程序必然无法运行。
解决方法是建立软链接/lib/ld64.so.1 => /lib64/ld-linux-x86-64.so.2，或者直接把库从/lib64中拷贝到/lib中来。完成库的修复后，再次执行app，结果一切正常。
尽管问题解决了，但bug的内在机理，bug的生成原因目前尚不知晓。推测与编译链接过程中的某些不当操作有关。
