For example, if we do
mkdir a
mkdir a/b
mkdir a/b/c
mkdir a/b/c/d
ln /bin/ls -s a/b/c/d/myls
ln a -s as
gdb as/b/c/d/myls
...
(gdb) r
Starting program: <mypath>/a/b/c/d/myls
^D
lldb as/b/c/d/myls
(lldb) r
Process 56636 launched: '<mypath>/as/b/c/d/myls' (x86_64)
We can see that gdb debugs on the canonical program, while lldb debugs on the linked program. How can we make gdb debug the linked program w/o getting its absolute path?
We can see that gdb debugs on the canonical program, while lldb debugs on the linked program.
No, we don't see this. We see that GDB performs a realpath to resolve the program, and lldb doesn't, but they both debug the exact same program.
Maybe you can use hard links instead?
This way, gdb will always refer to what you are looking for.
You can also play with with different version of gdb. It seems that version 7.11 provides what you want.
Take a look here:
~/tmp/link] stat hello
File: ‘hello’ -> ‘../hello’
This is what you get for version 7.12
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./link/hello...(no debugging symbols found)...done.
while for older gdb, you get
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from full_path/tmp/hello...(no debugging symbols found)...done.
So, play around with more recent release.
Related
my coredump file is produced by the shell command sudo spawn-fcgi fcgi-bin -a 0.0.0.0 -p 8089 &, fcgi-bin is compiled by the c++ command g++ -g fcgiMain.cpp fcgiEnv.cpp -o fcgi-bin etc. to deploy with nginx ,as we know that debug coredump file with the command gdb ./test_bin test_coredump,but now i have two bin program spawn-fcgi and "fcgi-bin",if i use the command gdb ./spawn-fcgi coredump and bt to look at the stack ,then it will look like this picture
so anybody can tell me how to deal with this coredump file ,thanks a lot!
There are two separate executables at play here: spawn-fcgi and fcgi-bin. The former execs the latter.
In the GDB output, you can see that the core was produced by fcgi-bin. Therefore, that's the executable you want to give to GDB:
gdb fcgi-bin coredump
I'm currently running a file manager program that abruptly crashed with a segmentation fault and dumped a core file. So I used gdb to debug the core file as:
gdb /path/to/executable /path/to/core
The program which I was running is written in C++. When I ran GDB and tried to print the source lines using "list", I got the following error:
(gdb) bt
#0 0x0000000000554286 in
MyFSEventManager::AddEvent(wxFileSystemWatcherEvent&) ()
#1 0x00000000005ab2e8 in
MyGenericDirCtrl::OnFileWatcherEvent(wxFileSystemWatcherEvent&) ()
(gdb) f 0
#0 0x0000000000554286 in
MyFSEventManager::AddEvent(wxFileSystemWatcherEvent&) ()
(gdb) l
1 /build/glib2.0-prJhLS/glib2.0-2.48.2/./glib/gmain.c: No such file or directory.
Why does gdb say this "/build/glib2.0-prJhLS/glib2.0-2.48.2/./glib/gmain.c: No such file or directory." I do not hit this issue with some other programs that I've debugged using gdb.
The operating system used is Ubuntu 16.04 running on Oracle virtual box. I think may be the gdb symbols were not loaded. I'm not sure why since I compiled the program using the "-g" option. I really need to know the source lines where the code crashes via gdb.
Any suggestions?
EDIT: changes after suggestions from Employed Russian
I was compiling my main using "-g" option and linking it to "existing" object files which were obviously not compiled using "-g" so when the core dumped, I could not see the source for these files. So I went ahead and recompiled those files with "-g" option and reproduced the core dump. It's able to show me the source lines now.
Why does gdb say this "/build/glib2.0-prJhLS/glib2.0-2.48.2/./glib/gmain.c: No such file or directory."
Because you really don't have that file on your system.
I think may be the gdb symbols were not loaded
GDB did load debug symbols for glib, but not for your main executable.
I'm not sure why since I compiled the program using the "-g" option.
Since we don't have your compile and link lines, we can't tell exactly what's wrong, but some of the common issues are:
You have a "stray" -s or -Wl,-s on your link line (this strips debug info from the resulting binary).
You have -g when compiling your main.c, but not when compiling the source in which MyFSEventManager::AddEvent() is defined
P.S.
(gdb) bt
This doesn't seem to be the complete output from bt command. Always try to paste complete outputs as it makes helping easier :)
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 want to make gdb rpm from gdb.spec file using rpmbuld which I can do without any problem but now in addition to that i want GDB to be complied with symbols so that when gdb is being attached to itself I should know the exact call flow and where exactly its failing.
Reason for doing this exercise is I am creating the application which will internally invoke gdb by calling gdb_init and going down failing with segmentation fault in gdb source code.
The easiest way to prevent stripping debug symbols
in rpm build is to add exit 0 at the end of %install.
The symbols are stripped by commands that are appended
to the %install scriptlet. Adding "exit 0" prevents the
commands from being run.
I don't know how you would to this with rpmbuild, but building gdb is really easy. Just get official source package, unpack it, then configure this way:
CFLAGS="-g3 -O0" path/to/gdb/source/configure --prefix path/to/your/installation/directory
make
make install
O0 is not strictly necessary, but if you want to debug a gdb crash, it will help.
I have a file called test. Even after compiling it with -g, when I run it in gdb, it says no debugging symbols found. I have also tried using -ggdb but it too was off no use. Please help.
Output for : gdb test
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 /usr/bin/test...(no debugging symbols found)...done.
The issue is that you are attempting to debug the wrong program.
Your program is called test and yet you are debugging /usr/bin/test (a system program that will almost certainly be shipped without symbols; even if it did contain symbols, they wouldn't relate to your source code).
gdb will search $PATH to find the executable. From here:
exec-file [ filename ] Specify that the program to be run (but not the
symbol table) is found in filename. gdb searches the environment
variable PATH if necessary to locate your program. Omitting filename
means to discard information on the executable file.
Try using the command:
$ gdb ./test
Remove a.out and then try again. It worked for me as I was also getting the same error.
rm a.out
gcc -g your_code.c
Check that the executable is not stripped, you can see that with file /usr/bin/test