c++ - 旧的 32 位 linux 程序如何最终调用 64 位库？

Question

我有一个旧的 32 位 C++ 应用程序，需要在 RedHatEL7 下运行。 RHEL7 安装了 32 位和 64 位版本的 libthread_db.so.1。但是不知何故，应用程序最终加载了/lib64/libthread_db.so.1。我怎样才能阻止这种情况发生？控制台日志显示:

mybox:/home/worknet$ which corbanames
~/bin/corbanames
mybox:/home/worknet$ file ~/bin/corbanames
/home/worknet/bin/corbanames: **ELF 32-bit** LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
mybox:/home/worknet$ locate libthread_db.so.1
**/usr/lib/libthread_db.so.1**
/usr/lib/i686/nosegneg/libthread_db.so.1
**/usr/lib64/libthread_db.so.1**
mybox:/home/myuser$ gdb corbanames
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7_4.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/myuser/bin/corbanames...done.
(gdb) r
Starting program: /home/myuser/bin/corbanames 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "**/lib64/libthread_db.so.1**".

Program received signal SIGSEGV, Segmentation fault.
0x080544a1 in getStackFrame<5> (this=<optimized out>) at StackCache.hpp:89
89  StackCache.hpp: No such file or directory.
Missing separate debuginfos, use: debuginfo-install glibc-2.17-196.el7_4.2.i686 libgcc-4.8.5-16.el7_4.2.i686 libstdc++-4.8.5-16.el7_4.2.i686
(gdb) bt
#0  0x080544a1 in getStackFrame<5> (this=<optimized out>) at StackCache.hpp:89
#1  fetchFrameData<5> (this=<optimized out>) at StackCache.hpp:76
#2  ECONZ::Leak::Impl::StackCache::StackCache (this=0xffffd01c)
    at StackCache.cpp:66
#3  0x08050c00 in ECONZ::Leak::Impl::HeaderList::doNew (size=32, 
    throwFlag=false) at leakTracker.cpp:138
#4  0x08050d83 in operator new (size=32) at leakTracker.cpp:284
#5  0xf79762ac in ACE_OS_Object_Manager::instance ()
    at Object_Manager_Base.cpp:185
#6  0xf7976357 in ACE_OS_Object_Manager_Manager::ACE_OS_Object_Manager_Manager
    (this=0xf7a2318c <ACE_OS_Object_Manager_Manager_instance>)
    at Object_Manager_Base.cpp:488
#7  0xf7976393 in __static_initialization_and_destruction_0 (__initialize_p=1, 
    __priority=65535) at Object_Manager_Base.cpp:504
#8  0xf79763cf in global constructors keyed to ACE_Object_Manager_Base::ACE_Object_Manager_Base() () at Object_Manager_Base.cpp:505
#9  0xf79c9816 in __do_global_ctors_aux ()
   from /usr/local/ACE_wrappers_32/lib/libACE.so.5.7.9
#10 0xf78ce475 in _init () from /usr/local/ACE_wrappers_32/lib/libACE.so.5.7.9
#11 0xf7fe9b5d in _dl_init_internal () from /lib/ld-linux.so.2
#12 0xf7fdb04f in _dl_start_user () from /lib/ld-linux.so.2
(gdb) 

Answer 1

看来我错了，正如@hgminh 和@PeterCordes 指出的那样——64 位库是调试的产物。 实际的 SIGSEGV 结果是对 __builtin_[frame|return]_address 的调用不是二进制兼容的。他们已经被重构。