I run this command in my terminal,
gcc -g -I/usr/include -g sample_client.c lsp.o lspmessage.pb-c.o -o sample_client -L/usr/lib -lprotobuf-c
in my file directory, I can see a sample_client file. Its property is executable.
However, when I run
(gdb) sample_client
I got this,
Undefined command: "sample_client".
How can I debug?
$ gdb ./sample_client
(gdb) run
To pass command-line arguments to your program use --args:
$ gdb --args ./sample_client arg1 arg2 arg3
(gdb) run
When you start gdb, you need to tell it which binary (executable) to debug:
$ gdb ./sample_client
Then, to run the program inside gdb, use the run command:
(gdb) run
You should probably give the fine documentation some quality time.
gdb <binary file here>
run < <flags here>
Also, refer to this quick reference for future operations:
http://www.stanford.edu/class/cs107/other/gdbrefcard.pdf
Related
I have been given a binary file with embedded C code which I cannot see when I run it in the GDB GCC Debugger. I imagine the C code has been hidden by the compilation / formation of the binary code. I have tried the following:
gdb> file myFile
gdb> list main
The output I get is:
myFile.c: No such file or directory
I know there is code written in C in this binary file. The executable runs when I type ./myFile
I have installed 32-bit libraries as this is needed for this situation and I'm running Ubuntu 16.04
Any help is appreciated.
It could be are a compilation issue. Try to look option for debugging
$ gcc -g myFile.c -o myFile
$ gdb myFile
(gdb) list main
If you compile without "-g" option, the debugger will never show you th C code but only the assembly code.
In your case, if you run these commands, you will see the disassembled code
(gdb) info file
Then take the address of the entry point
Entry point: 0x(address)
For show disassembly code
(gdb) break 0x(address)
(gdb) run
When the breakpoint gets caught
(gdb) x/20i $pc
To create the .out executable, I have to enter:
$: make
$: myprogram.out name.ged
My program incorporates a command line argument, thus the "name.ged".
Whenever I run gdb after getting a segmentation fault (core dumped), I enter:
$: gdb a.out core
(gdb): bt
I then use the back trace command, and gdb returns:
#0 0x4a145155 in ?? ()
#1 0x08a16ce0 in ?? ()
I even tried using the up command t move up the stack, but still no luck. I can't tell which line in my program is giving me the seg fault. gdb works with my other programs that do not involve a Makefile and command arguments, so I'm wondering if my commands are incorrect.
Summarizing the comments (before anyone else does :).
Your executable file is missing the symbolic information that gdb needs to display the relevant source code. You need to add the -g option to the compile command and produce a new executable. Then re-run your failing test to produce a new core file. gdb with this executable and core will be able to show you the stack of function calls using backtrace.
In a makefile, the easiest way to do this is to add (to) the CFLAGS variable which is used with the implicit .o.c rule.
CFLAGS= -g -Wall -Wextra
You can also add this directly to the command-line (assuming a decent shell :). This sets the value as an environment variable during the execution of the make command (and sub-commands).
$ CFLAGS='-g -Wall -Wextra' make
I'd actually recommend you add this to your bash .profile, so you always get the most information from the compiler.
CFLAGS='-Wall -Wextra'
Then, when you need it, put this in the makefile to make a debuggable executable:
CFLAGS+= -g
I need to pass some arguments to my application,that include the - symbol. The problem is if I pass gdb a.out -foo baa, the gdb understand that the arguments are for it, and not to my application. How to fix this?
gdb -q a.out
inside gdb:
run -foo baa
Tip: -q option for gdb suppresses the introductory copyright messages.
Option 1:
gdb --args ls /tmp
Option 2:
gdb ls
set args /tmp
run
Option 3 (didn't know about that, thanks Ahmed):
gdb ls
run /tmp
Maybe there are others?
I would like to create an executable of my two mycode.c and my main.c, how can I create an executable? i did
gcc mycode.c main.c
and it generates a a.out, but when i click it it would not run.. (i am new to this so please bear with me)
Thank you
Try this
gcc mycode.c main.c -o myprogram
Then run ./myprogram
If you double click it you probably won't see anything, you should instead try running it from the command line, where you compiled it from in the first place.
Your a.out might not be executable yet.
do:
$> chmod 755 a.out
or
$> chmod a+x a.out
then try running it:
$> ./a.out
I'm using GCC 4.4.1 and GDB 7.0-ubuntu on Ubuntu 9.10 (Karmic Koala). However, GCC won't generate debugger information when using any of the following switches: -g, -g3, -ggdb, or -ggdb3.
So when I run the program with GDB, it’s as if there wasn’t any debugger information generated. I have created very simple test source files in a new, empty folder.
Here is one example:
#include <stdlib.h>
#include <stdio.h>
int main (int argc, char **argv)
{
char msg[4];
// Allocate 4 bytes on the stack
strcpy (msg, "Hello, World!");
// Overflow
printf ("%s\n", msg);
return 0;
}
Here is my command line sequence:
gcc -g ./mytest.c -o mytest
gdb ./mytest
I have previously turned on MALLOC_CHECK_=1 in order to test the stack overflow problem in the code. And this works, so I get a stack trace. But the stack trace is no different whether I include the debug information or not. With the debugger information, I expected to see a line number of a file for where the problem occurred under GDB. However, this doesn't happen.
It works fine. I ran the debugger on my computer. I had to add
#include <string.h>
to compile it though. I called the file debugger.c. Here are the steps:
gcc -g debugger.c
gdb a.out
which will start the debugger
GNU gdb 6.3.50-20050815
...
...
(gdb) run
Starting program: /Developer/stackoverflow/extern/a.out
Reading symbols for shared libraries +. done
Program received signal SIGABRT, Aborted.
0x00007fff88040886 in __kill ()
(gdb) backtrace
#0 0x00007fff88040886 in __kill ()
#1 0x00007fff880e0e4f in __abort ()
#2 0x00007fff880d5693 in __chk_fail ()
#3 0x00007fff8802f851 in __strcpy_chk ()
#4 0x0000000100000f04 in main (argc=1, argv=0x7fff5fbff958) at debugger.c:9
(gdb)
But it seems like your problem isn't running the debugger, but getting the information where your code failed. You can use backtrace to achieve that.
You want:
gcc -g test.c -o mytest
gdb mytest
Never call anything "test" - it clashes with a shell built in. and "test.o" would by convention be the name of an object file, not an executable.
Your comment says you ran:
gcc -ggdb ./test.c -o test.o
That's probably not what you want.
gcc -ggdb -o mytest test.c
is likelier to be successful. If gdb ralphs on that then you have something wrong with your installation of gcc or gdb.