I was trying to install debug package of an application built by Yocto.
Aftre installation, the executables are found on .debug directory.
However, when I try to execute those I get the below error
-sh: /etc/.debug/app: cannot execute binary file: Exec format error
file command displays :
file /etc/.debug/app
/etc/.debug/app: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter *empty*, for GNU/Linux 2.6.32, BuildID[sha1]=1dfc051dc47683e0715b842998daadd4d12c541e, not stripped
arch command output is armv7l.
The app seems to be working fine [ the one with no debugg information].
And the file command on application is
file /etc/app
/etc/app: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=1dfc051dc47683e0715b842998daadd4d12c541e, stripped
What I want is to execute the application which is compiled using debug symbols, so that when the application crashes it gives coredump.
Is there a way to fix this or is there any other better method to run program using debug information [using Yocto framework ] ?
Debug packages contain just the debug symbols, you don't run them directly. Run the standard executables, and gdb will read the symbols that the debug package installed.
Related
【1】, I have a linux os environment, which is based on arm32(qemu similute).
【2】, There are two file in / directory. One is "init", and one is "nesoft", but i can only run "init", and i can not run "nesoft" :
/ # ./init
This is initramfs - init !!!
/ # ./nesoft
-/bin/sh: ./nesoft: not found
【3】, The two file have dirrerence below:
zhang#zhang-Virtual-Machine:~/src/qemu/third_patry/rootfs/busybox/rootfs$ file init
init: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=08c7f187d91207660caa2db0101980a1f4b12716, notd
zhang#zhang-Virtual-Machine:~/src/qemu/third_patry/rootfs/busybox/rootfs$ file nesoft
nesoft: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 4.4.0, stripped
【4】, I have search ,so i think "LSB shared object" should run as executable file (I learn form https://unix.stackexchange.com/questions/472449/what-is-the-difference-between-lsb-executable-et-exec-and-lsb-shared-object )
BUT, why it still does not run ?
【END】
Has anyone meet this before, and know why ?
The main difference I see that second file is dynamically linked which means it requires library .so files to execute. I suppose it just that can't load the dependency.
Try running ldd (or export LD_TRACE_LOADED_OBJECTS=1 before running your binary since ldd may not be on busybox) to see which library is missing.
I'm working with a Target board which use micro controller MCIMX6DP6AVT8AA - i.MX 6 series 32-bit MPU, Dual ARM Cortex-A9 core, 850MHz, FCBGA 624
(refer http://www.nxp.com/webapp/search.partparamdetail.framework?PART_NUMBER=MCIMX6DP6AVT8AA). My board run Linux kernel 3.1.1
I use cross-compile toolchain arm-poky-linux-gnueabi, run on host Ubuntu14.04 to build a Application for Target board. After built successful, i checked the output file as below
~$ file MyApp
MyApp: ELF 32-bit LSB executable, ARM, EABI5 version 1
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.1.1,
BuildID[sha1]=a800b4033343517d3368a3f3ca0c87eb98f6c1ba, not stripped
But when i run it on Target board, there was error
~$ ./MyApp
-sh: ./MyApp: No such file or directory
I don't know what i did wrong ?
The message is very likely coming from the dynamic linker. Look at the output of:
ldd MyApp
It will tell you all the library dependencies and where they are found on the system. Install those which hadn't been found.
My sshfs tool is currently crashing when performing a remote mount on a redundant debian system. I'm trying to install shfs-dbg and fuse-dbg to get the debug symbols to hopefully provide useful information on why it's crashing. I ran the apt install command for both packages and they run fine. But when I run file on sshfs and libfuse, it still reports them as "stripped" (which is without debug symbols as I understand it).
i.e. I'm seeing this:
/lib/x86_64-linux-gnu/libfuse.so.2.9.3: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=f189495dbaf2b058015ecb4e8f992da27b589ac3, stripped
/usr/bin/sshfs: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=494863c988c204bafaf02a3907ceb91e140235b7, stripped
When I should be seeing this:
sshfs: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=013de4f71447e974ec08bc4b784671a3072cf0c8, not stripped
lib/.libs/libfuse.so.2.9.4: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=bb4a5de2097be5e4e1725247da7d8972725a8c71, not stripped
What am I missing?
The debug symbols will be always stripped. The -dbg subpackage does not overwrite your binary files, but installs debuginfo into different files, where gdb and other debuggers can find them.
You can find where these files are by listing the files provided by the installed package:
dpkg query -L fuse-dbg
There is nothing more you need to do. Just run your favorite debugger and see where it crashes and what more information you can find in there.
My end goal is to write a C based application to run on a 32-bit linux ARM board as an embedded system. I am running a virtual 64-bit Ubuntu OS with Eclipse Neon and I am struggling with getting a useable executable file.
I have setup the cross compiler and I have made sure to build in 32-bit.
To check the file type and get more information on it I have used the command
> file hello.elf
I got sample hello world executable that does work and the output of the file command is
hello.elf: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armf.so.3, for GNU/LINUX 2.6.32, BuildID
This program runs just fine, the output of the file command for my program (be-brave) is as follows, side note it's a simple hello world, I called it be-brave for motivation
be-brave.elf: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/LINUX 3.2.0, BuildID
My guess is that the issue is the GNU/LINUX differemce meaning my cross compiler is not set right but I don't know for sure and even if that is the case I don't know how to fix it.
Any and all pointers/suggestions are greatly appreciated
I was able to find a workaround using the command line following this tutorial
Installing ARM cross compiler
I would still like to be able to use Eclipse so I will leave this question open in case anyone can help with that. I have a new issue, I am going to edit the original question to ask that
I was given a "binary" file on linux and a seperate file for windows for a particular task. The programs is an exe on windows. A linux version of the file has the same function on linux as it had windows, too.
However, I've failed to be able to execute this. I tried (on the terminal) to execute it by just the file name, ./[filename], and even tried chmod +x [filename] and then tried the second way.
For everything... I get the result: "Command not found". (The file is definitely there, by the way).
What am I supposed to do? The file command on it yields:
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=e805f746e65c09cc8b0c037d8a8c27ee0a6a051c
My guess is that this is 32 bit compile on a 64 bit system. I cross compiled a small c file into a binary using the -m32 option on gcc. This also needed a few extra packages. The resulting a.out looks like this.
% file a.out
a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=be02470c8337b96e7deaaff323bc53865991c3ab, not stripped
Compare this to a native system binary
% file /bin/ls
/bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=a0823e17cafbe5b2296346216445566840fdfd88, stripped
Running the a.out shows me this.
% ./a.out
zsh: no such file or directory: ./a.out
The specific "Command not found" message is something, I think, bash prints. I use zsh myself.
To get this to work, you can install the multilib packages. I didn't narrow it down to the exact package but installing gcc-multilib on Debian pulls in everything you need. After installing that, here's what I get.
% ./a.out
3.140523
(the program is supposed to estimate the value of PI).
Note: I actually needed to install gcc-multilib just to compile the file. I then uninstalled the packages to mimic a 64 bit system that doesn't have the 32 bit runtime libraries that the thing needs.
does the a.out have executable permission ?
check with ls -la cmd and if does no then add the permission using chmod a+x a.out an d then try executing