I am using GDB executable in my linux machine to debug my executable(rild).
My Executable details are as below :-
rild: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked (uses shared libs), BuildID[md5/uuid]=d100d90599eb3764018356c9ef3e1840, not stripped
however when I am running the command
./arm-linux-androideabi-gdb ~/android_gdb/system_bin/rild
I am getting follwing error:-
GNU gdb (GDB) 7.6
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 "--host=x86_64-linux-gnu --target=arm-linux-android".
For bug reporting instructions, please see:
<http://source.android.com/source/report-bugs.html>...
"/home/user/android_gdb/system_bin/rild": not in executable format: File format not recognized
I can see that GDB is also 64 bit version and the executable ELF is also unstripped, 64 bit. but still its not working.
rild: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV),
This is an aarch64 64-bit ARM binary.
This GDB was configured as "--host=x86_64-linux-gnu --target=arm-linux-android"
This GDB is a 64-bit x86_64 binary, configured to debug 32-bit ARM binaries.
The fact that GDB itself is a 64-bit binary is irrelevant. What matters is what target it is configured to debug. You need a different GDB, configured with --target=aarch64-linux-android.
Related
I'm tried to debug my binary file (called click) with gdb.
When I run
gdb ./click
I have the following error
GNU gdb (Ubuntu 7.10-1ubuntu2) 7.10
Copyright (C) 2015 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-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
"/home/student/Desktop/./click": not in executable format: File format not recognized
The outupt of:
uname -a
is
Linux student 4.2.0-36-lowlatency #42-Ubuntu SMP PREEMPT Thu May 12 23:39:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
And if I run
file click
I get this output:
click: ERROR: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2 error reading (Invalid argument)
Any ideas?
click: ERROR: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2 error reading (Invalid argument)
Your file is simply corrupt.
Possibly it is truncated (did you run out of disk space when linking it?), or you transferred it over FTP from another machine in ASCII mode (use binary mode instead).
I compiled the c++ code library at github.com/RainerKuemmerle/g2o using cmake after adding
set(CMAKE_BUILD_TYPE Debug)
so as to be able to debug the application. Then it created a build file named "g2o". But when I try debugging with gdb, this is the output I get.
user2#arm_machine:~/g2o/trunk/bin$ gdb g2o
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 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 "arm-linux-gnueabihf".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /scratch/mbaxkms7/ARM_Programs_mbaxkms7/g2o/trunk/bin/g2o...(no debugging symbols found)...done.
(gdb)
Is there any other way to generate debug information while using cmake?
Your approach with adding set(CMAKE_BUILD_TYPE Debug) works fine.
But g2o is the program which was build with Release options. Debug version of g2o is called g2o_d. Thus to debug you need launch debugger in the following way:
user2#arm_machine:~/g2o/trunk/bin$ gdb g2o_d
Note
Different names isn't common feature of CMake but only of the g2o project:
# postfix, based on type
SET(CMAKE_DEBUG_POSTFIX "_d" CACHE STRING "postfix applied to debug build of libraries")
SET(CMAKE_RELEASE_POSTFIX "" CACHE STRING "postfix applied to release build of libraries")
We have upgraded our C compiler to 4.5.3 and are now experiencing problems when trying to debug the server binary on solaris (works fine on linux rhel5 and AIX 6.1)
Below is the log of a debugging attempt. Any help would be appreciated.
-bash-3.00$ gdb myServer
Python Exception exceptions.ImportError No module named gdb:
warning:
Could not load the Python gdb module from `/usr/local/share/gdb/python'.
Limited Python support is available from the _gdb module.
Suggest passing --data-directory=/path/to/gdb/data-directory.
GNU gdb (GDB) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
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 "sparc-sun-solaris2.10".
Type "show configuration" for configuration details.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
BFD: BFD (GNU Binutils) 2.24.51.20140206 assertion fail elf.c:1727
Reading symbols from myServer...BFD: /data3/develop/myServer symbol number 7 references nonexistent SHT_SYMTAB_SHNDX section
Can't read symbols from /data3/develop/myServer: Invalid operation
(gdb)
BFD: BFD (GNU Binutils) 2.24.51.20140206 assertion fail elf.c:1727
This is a bug in gnu binutils. You should report it here.
I'm trying to read an ARM core file on my Linux desktop, but it seems not to be able to figure out my core file. Is there any way I can instruct gdb what type my core file is?
$ file ~/daemon
./daemon: ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared libs), for GNU/Linux 2.0.0, not stripped
$ file ~/core
./core: ELF 32-bit LSB core file ARM, version 1 (SYSV), SVR4-style, from './daemon -v -v -v -v -e 10 -t foo'
$ gdb-multiarch ~/daemon ~/core
GNU gdb (GDB) 7.5-ubuntu
Copyright (C) 2012 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-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from ./daemon...done.
"./core" is not a core dump: File format is ambiguous
(gdb) core-file ~/core
"./core" is not a core dump: File format is ambiguous
The generating platform is armv4, which gdb-multiarch claim to support, according to the "set architecture" list.
EDIT: To clarify, my desktop machine running gdb is "x86_64-linux-gnu", namely an 64-bit Intel Ubuntu box.
This may help:
$ gdb-multiarch
...
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) set gnutarget elf32-littlearm
(gdb) file daemon
...
(gdb) target core core
...
(gdb)
The following is relevant only if your desktop (where you are trying to run gdb-multiarch) is x86.
Gdb is a debugger. As such it will not be able to debug a foreign architecture executable on your x86 desktop machine because you cannot run arm code on x86 processor. You can however debug it remotely using gdb-server which will run on arm machine.
Is your desktop arm or x86?
Can 32bit gdb debug 64bit binary?
The answer above is incorrect. You need a 64-bit debugger to debug a 64-bit process. That's precisely the reason why gdb forks a 64-bit copy of itself behind the scenes.
Yes. A 32 bit gdb debugs 64 bit binaries fine on Solaris, at least on the latest release.
$ cat /etc/release
Oracle Solaris 11 Express snv_151a X86
Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved.
Assembled 04 November 2010
$ file /usr/bin/gdb
/usr/bin/gdb: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped, no debugging information available
$ file a
a: ELF 64-bit LSB executable AMD64 Version 1, dynamically linked, not stripped
$ gdb a
GNU gdb 6.8
Copyright (C) 2008 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 "i386-pc-solaris2.11"...
(gdb) b main
Breakpoint 1 at 0x400e9c: file a.c, line 3.
(gdb) run
Starting program: /tmp/a
Breakpoint 1, main () at a.c:3
3 printf("hello world !");
(gdb) quit
The program is running. Exit anyway? (y or n) y
$
However, if you look closer, this 32 gdb is launching a 64 bit gdb under the hood:
$ truss -f -t execve /usr/bin/gdb a
1793: execve("/usr/bin/gdb", 0x0804755C, 0x08047568) argc = 2
1793: execve("/usr/bin/amd64/gdb", 0x0804755C, 0x08047568) argc = 2
GNU gdb 6.8
Copyright (C) 2008 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 "i386-pc-solaris2.11"...
(gdb)
It does it regardless of whether the binary debugged is 32 or 64 bit.
I still think the way a debugger interact with a process under Solaris is size independent so technically, a 32 bit only binary debugger should be able to debug a 64 bit program.
A 64 bit gdb is able to debug both 32 bit and 64 bit binaries but a 32 bit gdb cannot debug 64 bit ones. This is what you are experiencing.