Can 32bit gdb debug 64bit binary? - gdb

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.

Related

CUDA-GDB view variables in C/C++

I have installed the latest version of the CUDA drivers available from NVIDIA
mmiller#host:~/NVIDIA_CUDA-7.5_Samples$ nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2015 NVIDIA Corporation
Built on Tue_Aug_11_14:27:32_CDT_2015
Cuda compilation tools, release 7.5, V7.5.17
But when I debug a program I get an error message about python.
mmiller#csit-crackin:~$ cuda-gdb hello.out
NVIDIA (R) CUDA Debugger
7.5 release
Portions Copyright (C) 2007-2015 NVIDIA Corporation
GNU gdb (GDB) 7.6.2
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-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/mmiller/hello.out...done.
(cuda-gdb) b main
Breakpoint 1 at 0x402546: file hello.cu, line 3.
(cuda-gdb) r
Starting program: /home/mmiller/hello.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main () at hello.cu:3
3 foo: int x = 1;
(cuda-gdb) s
4 int y = x+1;
(cuda-gdb) p x
Python Exception <type 'exceptions.AttributeError'> 'gdb.Type' object has no attribute 'name':
Python Exception <type 'exceptions.AttributeError'> 'gdb.Type' object has no attribute 'name':
$1 = 1
(cuda-gdb)
I the program is a very simple program and I read that it may be an error dealing with python and gdb, but I am unsure of how to fix the error using the latest software from Ubuntu and Nvidia. Any suggestions as to how to fix this?
It appears that Ubuntu will not update the path to include the latest version of nvcc and cuda-gdb. You have to update the path (or change the symlinks) manually for your to reference the correct versions of these libraries.

Not in executable format: File format not recognized GDB

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).

GDB not able to recognise executable which is unstripped

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.

cross compiled core dump analysis [duplicate]

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?

How to use macports to configure my GDB version on Mac Mountain Lion

I have just used macports to install on my Mac the newest gdb by using sudo port install gdb. The problem is when I type gdb in the command line it still shows the old version. How can I switch to the new one I just installed?
Thanks.
Type :
port contents gdb
It gives you where is located the port
/opt/local/bin/ggdb
/opt/local/include/ansidecl.h
/opt/local/include/bfd.h
/opt/local/include/bfdlink.h
/opt/local/include/dis-asm.h
/opt/local/include/gdb/jit-reader.h
/opt/local/include/symcat.h
/opt/local/lib/libbfd.a
/opt/local/lib/libbfd.la
/opt/local/lib/libopcodes.a
/opt/local/lib/libopcodes.la
...
As you can see below it is named ggdb, not gdb when you have installed it with MacPorts
ggdb
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 "x86_64-apple-darwin11.4.2".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb)