What could make GDB refuse to break?

Question

I'm at a loss here. I'm writing a compiler in C (for hobby), and compiling with GCC 4.6.1 on amd64 Linux 2.6.32, using GDB 7.3. Flags are "-Wall -Wextra -O0 -g", in addition to the usual -I and whatnot. I have a function whose purpose is to report a parse error, defined as follows:

void cerror_at (struct lex *lex, struct token *tok, const char *fmt, ...)

Other than being variadic, nothing weird. The problem is that GDB will NOT break at it. I've tried every way I can think of (breakpoint at the function, inside the function, before it's called, you name it), but as soon as my program is inside the function, I get messages like "warning: Error removing breakpoint 0" and GDB just lets the program finish. There's nothing wrong with it any more (I've since fixed the bug I was trying to find, and everything runs as it should), but I can't get into the function. Any ideas on what could cause this?

Edit: More information! GDB is setting the breakpoint at 0x403057. The function starts at 0x403025. Look at this part of the disassembly:

0x0000000000403053 <+46>:   test   %al,%al
0x0000000000403055 <+48>:   je     0x403077 <cerror_at+82>

At this point, it skips ahead to 0x403077 (past the breakpoint). I've verified that placing the breakpoint at an address before the "je" works, as well as at an address at or after 0x403077, the target of the jump, but not in between (where GDB is trying to place it). Why would GDB place the breakpoint in the middle of the function? Even GDB tells me that the function's address is, in fact, 0x403025.

Answer 1

Maybe I'm just dense, but the most common reasons I've come across for a debugger to refuse to break are the most simple ones.

1. The code that I'm trying to debug doesn't exactly match the code in the debugger.
2. I forgot to compile that library with debugging options.

Be sure you check both of these anytime you get a debugging error like this, even if you think it's not the problem.

Answer 2

This sounds like a bug in GDB. In particular, Error removing breakpoint 0 is very suspicious (it's a breakpoint GDB automatically inserted somewhere; user-inserted breakpoints have positive numbers).

You should probably try to create a reduced test case and file a bug here.