Cannot create a breakpoint in a file using gdb

gdb GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-32.el5_6.2)
g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-50)

Compiling with the following cflags:

CFLAGS = -Wall -Wextra -Wunreachable-code -ggdb -O0

I have also tried using just -g as well, but that didn't work either.

I have a file call demo.cpp and I am trying to create a break point in that file.

My executable target is called demo_app. I run gdb using the following:

gdb demo_app

I try and create the break point

b demo.cpp:997

gdb returns the following message:

No source file named demo.cpp.
Make breakpoint pending on future shared library loa开发者_如何学JAVAd? (y or [n]) n

The executable file properties:

ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped

However, I have another file called video.cpp and I can create break points in that file.

Many thanks for any advice,

================== UPDATE I have done the following:

(gdb) start
Temporary breakpoint 1 at 0x804ba44
Starting program: /home/user/video_demo/demo
warning: .dynamic section for "/lib/libc.so.6" is not at the expected address
warning: difference appears to be caused by prelink, adjusting expectations
warning: .dynamic section for "/lib/libuuid.so.1" is not at the expected address
warning: difference appears to be caused by prelink, adjusting expectations
[Thread debugging using libthread_db enabled]
[New Thread 0x1ab7b90 (LWP 5123)]

(gdb) b demo.cpp:1038
No source file named demo.cpp.
Make breakpoint pending on future shared library load? (y or [n]) n

================= MAKEFILE ========

OBJECT_FILES = demo.o video.o
CFLAGS = -Wall -Wextra -Wunreachable-code -ggdb -O0 
CC = g++ -m32
TARGET = demo

# Include path
INC_PATH = -I /usr/network/inc
INC_PATH+= -I sdp/inc

# Library path
LIB_PATH = -L /usr/network/lib
LIB_PATH+= -L sdp/lib

# Libraries to include
LIBS = -lnetwork -lsdpAPI -lpthread

# Linker run-time path
LDFLAGS = -Wl,-rpath=/usr/network/lib
LDFLAGS+= -Wl,-rpath=sdp/lib

$(TARGET): $(OBJECT_FILES)
    $(CC) $(CFLAGS) $(LDFLAGS) $(INC_PATH) $(OBJECT_FILES) $(LIB_PATH) $(LIBS) -o $(TARGET)

demo.o: demo.cpp video.cpp
    $(CC) $(CLFAGS) $(INC_PATH) $(LIB_PATH) $(SDP_LIB) -c demo.cpp

video.o: video.cpp
    $(CC) $(CFLAGS) $(INC_PATH) $(LIB_PATH) -c video.cpp

clean:
    rm -f $(OBJECT_FILES) $(TARGET) *~

There's a mistake in your makefile - CLFAGS instead of CFLAGS in the recipe for demo.o.

You should be able to catch that if you watch the output when you run make - you'll see missing compiler options when building just that one object, since CLFAGS is an empty variable.

And of course, there's something to be said for taking advantage of the built-in recipes. If you store all your options in the variables make expects by default, you won't have to rewrite recipes and have that chance for typos. For example, append $(INC_PATH) to CPPFLAGS. (And you shouldn't need to pass any linker flags to compile-only steps like you're doing.)

There are several possible explanations:

1. The most likely one is that demo.o (result of compiling demo.cpp) is not linked into the final executable. This could happen if you put demo.o into an archive library, and your main.o doesn't reference any symbols from demo.o
2. Your demo.o is really not built with the -ggdb flag
3. There is a bug in your GCC or your GDB

To confirm or refute 1, run nm demo.o, then nm demo_app, and verify that symbols from demo.o are present in the final executable.

To confirm or refute 2, run make clean && make all > make.log 2>&1, then see what command line was actually used to build demo.o

If you can refute both 1 and 2, then 3 is the only possibility I can think of at the moment. You can use readelf -w demo_app, and see whether it has references to demo.cpp. If it does not, the bug is in GCC. If it does, the bug could be in either GCC or GDB.

EDIT: Thank you for providing the Makefile. You are building an executable called demo. You claim to debug demo_app. PEBKAC?

Say start as your first gdb command. Let the program load. Then try setting the breakpoint. It should then not prompt you regarding future library loading. Assuming the breakpoint is set as it should be, then do continue.