My server is a Amazon Linux AMI 64bits (2014.09-release-notes)
I compiled a program coded in C++ (gcc48-c++.x86_64 is installed) :
[root#ip-***-**-**-*** waveform_generator]# make
Compiled [src/main.cpp] >> [src/main.o]
Compiled [src/File.cpp] >> [src/File.o]
Compiled [src/AGenerator.cpp] >> [src/AGenerator.o]
Compiled [src/GeneratorSVG.cpp] >> [src/GeneratorSVG.o]
Compiled [src/GeneratorCanvas.cpp] >> [src/GeneratorCanvas.o]
Compiled [src/GeneratorPNG.cpp] >> [src/GeneratorPNG.o]
Compiled [src/Header.cpp] >> [src/Header.o]
Compiled [src/pngwriter.cpp] >> [src/pngwriter.o]
Built [wfgen]
Now when I execute the compiled file "wfgen" the console return this message :
[root#ip-***-**-**-*** waveform_generator]# bash wfgen
wfgen: wfgen: cannot execute binary file
Environment :
[root#ip-***-**-**-*** waveform_generator]# uname -i
x86_64
[root#ip-***-**-**-*** waveform_generator]# file wfgen
wfgen: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, BuildID[sha1]=2e7c881c6fc10f12cdf49402edae1cc36b8d77a0, not stripped
Do you have a solution to my problem?
Thank you a lot :)
Max.
When you type
[root#ip-***-**-**-*** waveform_generator]# bash wfgen
I think bash expects wfgen to be a shell script. Instead you could directly type the program name at th e prompt
[root#ip-***-**-**-*** waveform_generator]#./wfgen
It looks like the compiling went fine, the output of the file command looks good. I don't know what's in the Makefile, but guess it'll be fine, too.
I don't really know your environment, so I'm taking a bit of a guess here: If everything else went fine, and you still get the cannot execute binary file error, then it can be because your filesystem is mounted with the noexec option.
To check if that's the case, run mount, then determine under which mount point the current directory is, and check if the noexec mount option is set for this mount point.
If it's indeed the noexec problem, you have two options:
Remount the filesystem without the noexec option. If you want this to be permanent, don't forget to edit /etc/fstab. (Note however that noexec might be there for a reason. Make sure it's ok to remove it.)
If it's only one binary, move it to a filesystem that doesn't have the noexec restriction and try from there. A good place would be the /usr/local/bin directory (or /usr/local/sbin, if it's an administrative tool.)
Related
Main question:
In Ubuntu trying to debug an embedded application running in QNX, I am getting the following error message from gdb:
warning: Shared object "$SOLIB_PATH/libc.so.4" could not be validated and will be ignored.,
Q: What is the "validation" operation going on ?
After some research I found that the information reported by readelf -n libfoo.so contains a build-id and that this is compared against something and there could be a mismatch causing gdb to refuse to load the library. If that's the case what ELF file's build-id is the shared object's build-id compared against ? Can I find this information parsing the executable file ?
More context:
I have a .core file for this executable. I am using a version of gdb provided by QNX and making sure I use set sysroot and set solib-search-path to where I installed the QNX toolchain.
My full command to launch gdb in Ubuntu is :
$QNX_TOOLCHAIN_PATH/ntox86_64-gdb --init-eval-command 'set sysroot $SYSROOT_PATH' --init-eval-command 'set solib-search-path $SOLIB_PATH --init-eval-command 'python sys.path.append("/usr/share/gcc-8/python");' -c path-to-exe.core path-to-executable-bin
Gdb is complaining that it cannot load shared objects :
warning: Shared object "$SOLIB_PATH/libc.so.4" could not be validated and will be ignored.
The big thing here is to make sure you're using the exact same binary that is on the target (that the program runs over). This is often quite difficult with libc, especially because libc/ldqnx are sometimes "the same thing" and it confuses gdb.
The easiest way to do this is to log your mkifs output (on the linux host):
make 2>&1 | tee build-out.txt
and read through that, search for libc.so.4, and copy the binary that's being pulled onto the target into . (wherever you're running gdb) so you don't need to mess with SOLIB paths (the lazy solution).
Alternatively, scp/ftp a new libc (one that you want to use, and ideally one that you have associated symbols for) into /tmp and use LD_LIBRARY_PATH to pull that one (and DL_DEBUG=libs to confirm, if you need). Use that same libc to debug
source: I work at QNX and even we struggle with gdb + libc sometimes
Wanted to use gdb as a debugger in Linux Debian. Trying to run a binary I get this:
(gdb) r
Starting program: /usr/local/sbin/test
/bin/bash: /usr/local/sbin/test: No such file or directory
During startup program exited with code 127.
(gdb)
I guess it's supposed to be elementary. But I googled a lot and most common answer is
$ export SHELL=/bin/bash
This doesn't help. I also tried to change PATH for binaries execution, tried to run from different directory... Still the same.
Could you please help me with that?
/bin/bash: /usr/local/sbin/test: No such file or directory
There are two common causes of this:
the file /usr/local/sbin/test doesn't exist
the file does exist, is a dynamically linked executable, and the ELF interpreter that it specifies does not exist.
For #1, the answer is obvious: you need a file to debug.
For #2, you can find out which ELF interpreter the file requires like so:
readelf -l /usr/local/sbin/test | grep interpreter
You likely have a 32-bit binary pointing to /lib/ld-linux.so.2 on a 64-bit system without 32-bit runtime support installed. Depending on the distribution you are using, something like sudo apt-get install libc6:i386 should do the trick.
Recent versions of the file command also print the interpreter:
file ./a.out
./a.out: ELF 32-bit LSB executable, ... interpreter /lib/ld-linux.so.2, ...
This worked for me:
export SHELL = path
as in your case:
export SHELL=/usr/local/sbin/test
It may help you. Allow all users to execute the file like this before gdb.
chmod +x file
I had the same problem on centos7, and solved it by installing gdb8.1.
I have a .bat (Batch) file compiling an OS I am making in Windows 7. I use nasm to compile the code, then dd and imdisk. Although probably not worth mentioning, after compilation I use mkisofs to make a .iso then VirtualBox for testing.
When it gets past "Copying kernel and files to disk" it (the output in the prompt) says The volume does not contain a recognized file system. Please make sure that all required file system drivers are loaded and that the volume is not corrupted. 0 file(s) copied.
It compiled before in which I could properly test the OS and some text would appear, then I noticed nothing appeared on the screen anymore, so I further looked at the prompt output and batch file and realized this.
Can anyone give me some help here? I really want it to compile.
Here is the main part that errors in my batch file:
echo Adding boot to disk
cd build
dd if=..\src\boot\boot.bin bs=512 of=myos.flp
cd ..
echo Mounting disk image
imdisk -a -f build\myos.flp -s 1440K -m B:
echo Copying kernel and files to disk
copy src\kernel.bin b:\
echo Dismounting disk image
imdisk -D -m B:
I am able to successfully compile MikeOS (my inspiration) with pretty much the same commands (I modified the MikeOS buildwin.bat to use dd), so I have no idea what is happening.
EDIT: I even tried this in Ubuntu with dd and it doesn't work! When I get to the mount part it says something about the filesystem...I think my dd command is wrong, but for some reason I can compile MikeOS correctly. Ugh.
The boot file should always be in the first sector. Try this:
dd seek=0 if=..\src\boot\boot.bin bs=512 of=myos.flp
seek=0 copies the boot file to the first sector. If you don't put it, the dd command may copy the file to somewhere else.
I'm trying to debug a CUDA program, but when I'm launching gdb like so:
$ gdb -i=mi <program name>
$ r <program arguments>
I'm getting:
/home/wvxvw/Projects/cuda/exercise-1-udacity/cs344/HW2/hw:
error while loading shared libraries: libcudart.so.5.0:
cannot open shared object file: No such file or directory
Process gdb-inferior killed
(formatted for readability)
(I'm running gdb using M-xgdb) If that matters, then CUDA libraries are in the .bashrc
export PATH="/usr/local/cuda/bin:$PATH"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/cuda/lib64"
error while loading shared libraries: libcudart.so.5.0
This error has nothing to do with GDB: your executable, when run from inside GDB, can't find the library it needs.
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/cuda/lib64"
GDB runs your program in a new $SHELL, so that should have worked. I wonder if there is some interaction with emacs.
In any case, this:
(gdb) set env LD_LIBRARY_PATH /usr/local/cuda/lib64
(gdb) run
should fix this problem.
Update:
as I've mentioned it before, ld path is set properly
No, it isn't. If it was, you wouldn't have the problem.
Now, I don't know why it isn't set properly. If you really want to find out, start by running GDB outside emacs (to exclude possible emacs interactions).
If the problem is still present, gdb show env, shell env, adding echo "Here" to your ~/.basrc, etc. should help you find where things are not working as you expect them.
I've had this problem as well. One way to look at it is that even if the LD_LIBRARY_PATH variable is correct when you enter show env into gdb, it may not be correct when you actually execute the program because gdb executes $SHELL -c <program> to run the program. Try this as a test, run $SHELL from the command line and then echo $LD_LIBRARY_PATH. Is it correct? If not, then you probably need to add it to your rc (.tcshrc in my case).
I had a similar problem when trying to run gdb on windows 7. I use MobaXterm to access a Linux toolbox. I installed gdb separately from http://www.gnu.org/software/gdb/ . I got it to work by making sure gdb could find the correct .dll files as mentioned by Employed Russian. If you have MobaXterm installed the .dll files should appear in your home directory in MobaXterm/slash/bin.
gdb however did not recognize the LD_LIBRARY_PATH variable. For me, it worked when I used the PATH variable instead:
(gdb) set env PATH C:\Users\Joshua\Documents\MobaXterm\slash\bin
(gdb) run
I would think using PATH instead of LD_LIBRARY_PATH might work for you provided you put the correct path to your library.
gdb is looking for a library, so why are you concerned with the include path? You may want to try to set the gdb option "solib-search-path" to point to the location of the libcudart.so.5.0 library.
I have two different version of a library let's say
libxyz.so
at two different location
1) /home/maverick/dev/libxyz.so ( development Version)
2) /home/maverick/prod/libxyz.so ( Production Version )
I have a setup that compile my program and link with appropriate version of the library depending on LD_LIBRARY_PATH. for example If I want to link my program with dev version of libxyz.so i change my LD_LIBRARY_PATH to add /home/maverick/dev and if I want to link with prod version I change LD_LIBRARY_PATH to add /home/maverick/prod instead.
I compiled my program by linking with dev version and the output of
ldd MyProg
is
libxyz.so => /home/maverick/dev/libxyz.so
If i run the program it loads the libxyz.so from
/home/maverick/dev/libxyz.so
and runs fine.
it this point my LD_LIBRARY_PATH includes /home/maverick/dev not /home/maverick/prod
but when I try to debug this program through GDB
gdb MyProg
it loads the libxyz.so from location
/home/maverick/prod/libxyz.so
I have trouble making GDB load the correct version of the library during debug. So till now what I am doing is first launch the program (that load the dev version) and attach gdb to that PID this way its works fine. but if it run like
gdb MyProg
it dosen't
I tried every thing to fix this like setting up sysroot, solib-search-path in GDB but nothing is working.
if fact when I set up sysroot to point to the debug version of the library gdb gave some message like
.dynamic section for XXX is not at the expected address
any suggestion would be appreciated.
I have trouble making GDB load the correct version of the library during debug.
Let me guess: you are using tcsh, right?
The problem most likely comes from yoour ~/.cshrc resetting LD_LIBRARY_PATH to /home/maverick/prod.
When you run the program in GDB, it executes $SHELL -c your-program [args...] (so as to allow you to use I/O redirection).
Solution: don't touch environment in your .cshrc for non-interactive shell, e.g. start it with:
if ($?prompt == 0) exit