4
[root@localhost Relay]# file RelayD
RelayD: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped

[root@localhost Relay]# ./start
: no process killed
./start: line 2:  2066 Segmentation fault      ./RelayD start --daemon
: command not found
[root@localhost Relay]# gdb RelayD
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-92.el6)
Copyright (C) 2010 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/>...
"/home/Relay/RelayD": not in executable format: File format not recognized
(gdb) run
Starting program:
No executable file specified.
Use the "file" or "exec-file" command.

How to debug this file? I have tried to run gdb to debug the file and the result show: not in executable. The program is showing segfault when I tried to run the bin file.

0xC0000022L
  • 10,908
  • 9
  • 41
  • 79
sycoi001
  • 53
  • 1
  • 1
  • 4
  • If I find the time, I'll give it a try to run a CentOS that's on par with your RHEL and outline the steps in greater details. Or you could do that yourself in an answer to your own question, even if it's in part based on my answer. – 0xC0000022L Jul 06 '18 at 09:16

1 Answers1

0

It seems you may be looking for:

gdb --args ./RelayD start --daemon

(although you probably want to avoid --daemon if that's optional).

However, that above (shell) command is equivalent to:

gdb ./RelayD

... followed by (on the GDB prompt):

run start --daemon

Note how in both cases I am passing the arguments as per the script line and how I am passing the relative path instead of merely the name of an executable.

There may be another catch here, but it's hard to tell and you don't explicitly mention the distro you're on. However, it's possible that for your system you need to enable multilib support [1] so that your x86-64 OS can run x86-32 binaries (that RelayD ELF file) and that you may have to install some packages you have to install in order to have GDB support this scenario. The alternative could be to run a 32-bit container (which still requires multilib, if I am not mistaken) and inside that prepare and debug with a 32-bit GDB or use a 32-bit VM to get the debugging done. But for all I know most distros support the scenario of debugging a 32-bit binary on the 64-bit host system. So it's likely a matter of installing some extra packages.

Oh and last but not least you may be missing some of the shared objects (libraries) that the 32-bit executable expects. Use readelf or ldd on your RelayD to find out more.

[1] yum groupinstall "Compatibility Libraries" should do the trick, provided multilib_policy=all is set in your yum.conf and you're indeed running on RHEL (or CentOS or Scientific Linux) as suggested by the GDB output you gave. Also make sure yum.conf does not contain exclude = *.i?86 to preclude the 32-bit packages from being considered (exactarch=1 may also have an adverse effect, so consult man yum.conf). You can also pick and choose your own compatibility libraries by searching the list with yum search compat|grep ^compat-.

0xC0000022L
  • 10,908
  • 9
  • 41
  • 79
  • When I try to bull command ldd, it show: [root@NguyenSy Relay]# ldd RelayD statically linked – sycoi001 Jul 06 '18 at 09:17
  • But when use command: [root@NguyenSy Relay]# file RelayD RelayD: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped What are difference between statically linked and dynamically linked bro? Thank you – sycoi001 Jul 06 '18 at 09:19
  • Given how ldd works that makes sense. You may have to use readelf instead (which doesn't use the loader) or install a 32-bit linker first, so ldd can do its job. Otherwise, I reckon, something fishy is going on ... – 0xC0000022L Jul 06 '18 at 09:26