GCC does not generate debugger information when using -g, -ggdb, -g3, or -ggdb3

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. 开发者_StackOverflowI 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.