In my project, I build three applications, in my Linux host machine.
Output binaries are,
main_process
update_data
db_process
Questions:
gdb handles only one executables to debug at one time?
All these three executables can't be run once in gdb?
When I run,
gdb ./main_process
Error message from gdb:
(gdb) r
Starting program: /home/iir/bin/
warning: `/lib/ld-linux.so.2': Shared library architecture i386 is not compatible with target architecture i386:x86-64.
warning: `/lib/ld-linux.so.2': Shared library architecture i386 is not compatible with target architecture i386:x86-64.
Failed to read a valid object file image from memory.
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7dda402 in ?? () from /lib/ld-linux.so.2
(gdb) bt
#0 0x00007ffff7dda402 in ?? () from /lib/ld-linux.so.2
Backtrace stopped: Cannot access memory at address 0x10074
EDIT: This question got downvotes, I want to mention here, the segfault caused because of running arm binaries in GDB. I've noticed that its bug in our build system where it didn't build actually for the arm arch instead x86.
Error message from gdb
(gdb) r
Starting program: /home/iir/bin/
The error message says that you are trying to execute /home/iir/bin/ which appears to be a directory. It is very unlikely that this is the actual result you observed after running gdb ./main_process.
Conclusion: you are not telling us what you actually did and what you observe, and trying to guess what that might be is a waste of time.
This question got downvotes, I want to mention here, the segfault caused because of running arm binaries in host GDB.
I've noticed that its bug in our build system where it didn't build actually for the arm arch instead x86.
Questions:
gdb handles only one executables to debug at one time?
Answer: Yes and I can able to pass another executable in as an argument using run.
All these three executables can't be run once in gdb?
Answer: No.
Related
helloworld.c:
int main(){}
[1] 9845 illegal hardware instruction (core dumped) LD_PRELOAD=./libc.so.6 ./helloworld
This preload libc is an old version of glibc
Can I debug helloworld linking it on my system?
Or is there a fast way to deploy a virtual machine with the specific version of shared libraries?
Can I debug helloworld linking it on my system?
Yes, but you need to do it correctly. This answer provides details, and an explanation for why your LD_PRELOAD didn't work.
From your post I could see POC dumping core. So, better use gdb to analyze the coredump and see the crashing callstack. Make sure you load the right libc in gdb while analyzing coredump.
Else use LD_DEBUG=all before invoking POC and see if any pointers to crash by seeing the details during runtime.
I am trying to debug Linux using gdb, I compiled kernel with "compile kernel with debug info".
once kernel is compiled I am trying to give
GDB file vmlinux
(running above command gives me below error)
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Reading symbols from file...(no debugging symbols found)...done.
"/home/Linux/vmlinux" is not a core dump: File format not recognized
Even I am setting debug con-figs it is giving me "no debugging symbols found"
kernel debugging is a whole different ballgame from debugging a user process and is not as simple as firing up GDB. For this you will need support of a JTAG.
QEMU allows you to virtualize a machine and therefore use a virtual JTAG.
For simple stuff you will probably find printk much easier.
I try to debug some native code on Android with GBD. The code wasn't created by me and is not in an Android project, so I can't use the ndk-gdb tool. I use gdbserver on the android machine and connect to it from my mac with the normal GDB program. I try to load all the libraries (which should have symbols according to objdump tool), but gdb tells me that it does not load the symbols (according to the gdb command “info sharedLibrary”). These are the steps I took:
start gdbserver on Android machine
start GDB with the debug version of the binary
gdb symbols/system/bin/mediaserver
the following commands are executed in gdb itself
tell gdb where to look for the libraries with symbols
(gdb) set solib-search-path symbols/system/lib
tell gdb where to find the source files
(gdb) directory /sources
connect to remote target (Android machine)
(gdb) target remote 192.168.1.10:5039
GDB connects successfully to the running binary and I can pause and continue the execution. But it does not show me any debug information like function names or line numbers. It only shows adresses. When I check the status of the used libraries, I see that gdb thinks, they don’t have any symbols:
command in gdb:
(gdb) info sharedLibrary
From To Syms Read Shared Object Library
0x00003700 0x0000ff0c Yes /symbols/system/bin/linker
No libc.so
No libstdc++.so
No libm.so
No liblog.so
No libcutils.so
No libspeexresampler.so
No libaudioutils.so
No libgccdemangle.so
No libamplayer.so
Now for example the last library. When I check with the file command (not in gdb), it tells me that it is a not stripped library (the library is located in the "symbols/system/lib" folder).
file libamplayer.so
Output:
libamplayer.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped
objdump command shows a lot of symbols in it (I don’t show the output because it’s very long). So why does gdb not recognise the symbols in this libraries? I thought, at least line numbers and function names are present in not stripped versions of libraries. Or am I wrong? It would be very nice if someone could give me more insight.
Thanks!
System info:
GDB Version: 7.3.1-gg2 on Mac OS X Mavericks
The code wasn't created by me and is not in an Android project, so I can't use the ndk-gdb tool.
Your conclusion does not at all follow. ndk-gdb should be able to debug any Android program, whether created as a "project" or via other means.
I use gdbserver on the android machine and connect to it from my mac with the normal GDB program.
The normal GDB is likely not configured for cross-debugging, and thus doesn't understand ARM binaries at all. I am surprised you get as far using it as you do.
In the documentation for gdb:
The tracepoint facility is currently available only for remote
targets. See section Specifying a Debugging Target. In addition, your
remote target must know how to collect trace data. This functionality
is implemented in the remote stub; however, none of the stubs
distributed with GDB support tracepoints as of this writing.
Emphasis mine. Where can I get such a stub (for C/C++ code compiled with GCC on Debian x86 or x64)? Or how do I go about making one? The documentation on writing stubs only mentions implementing functions to communicate with the serial ports. Thanks!
I don't know much about remotes but some targets in gdb now do support tracepoints
there is possibly a way to get at this using a 'normal' gdb info or show command, I could not find it. in the output below tracepoints are supported due to the 'supported=1',
this may not be limited to the gdb stub, but also the kernel the stub is running on.
$ gdbserver/gdbserver :12345 ~/tests/test &
$ gdb -quiet
(gdb) file ~/tests/test
Reading symbols from /home/ratmice/tests/test...done.
(gdb) target remote :12345
Remote debugging using :12345
Remote debugging from host 127.0.0.1
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00000035dd600b20 in _start () from /lib64/ld-linux-x86-64.so.2
Created trace state variable $trace_timestamp for target's variable 1.
Missing separate debuginfos, use: debuginfo-install glibc-2.13-2.x86_64
(gdb) interpreter-exec mi2 -trace-status
^done,supported="1",running="0",frames="0",frames-created="0",buffer-size="5242880",buffer-free="5242880",disconnected="0",circular="0"
Please clarify ..
I have a multithreaded 64 bit C process running on sun10 server. It is occupying 2.2 GB of RAM.
When I take the gcore and debug it, it is showing me "no symbol table" on GDB prompt. Hence i am not able to debug anything.
The binary is not stripped and compiled with -g gcc option .The gcore if of 32 bits.
Why the procress image is not showing any symbols ??
Thanks-
viva
Did you try to start gdb with both executable file and core dump file?
gdb executable core
This will load symbols from executable and memory dump from core.
As said in gdb manual,
Traditionally, core files contain only some parts of the address space of the process that generated them.