阻止GDB单步执行glibc函数

Question

^{Sorry for the nondescript title, couldn't think of anything better.}

When I run my program through GDB to find a Segmentation Fault, I get thousands of lines of this garbage:

(gdb) step
_IO_new_file_xsputn (f=0x76fa0b40 <_IO_2_1_stdout_>, data=0x7efff284, n=7) at fileops.c
1279    fileops.c: No such file or directory.
(gdb) step
1273    in fileops.c
(gdb) step
1279    in fileops.c
(gdb) step
1286    in fileops.c
(gdb) step
1288    in fileops.c
(gdb) step
1289    in fileops.c
(gdb) step
1292    in fileops.c
(gdb) step
1294    in fileops.c
(gdb) step
1292    in fileops.c

...and on and on and on. It makes debugging very difficult and tedious because:

• I must type step (or press Enter ) repeatedly.
• I can hardly ever even see the output of my program, as it's hidden in pointless information.
• If I'm pressing Enter repeatedly, I often miss the Seg Fault I'm looking for.

How can I tell gdb to quit printing the lines like this?

1273     in fileops.c

Is there some config file or command-line option I can use?

Answer 1

How can I tell gdb to quit printing the lines like this?

By using the step command, you asked GDB to print exactly this info.

If you don't want that info, you should stop asking for it.

I often miss the Seg Fault I'm looking for.

If you simply run , GDB will automatically stop when you get a SIGSEGV , you can't miss that.

What you probably want is to stop in your code some time before the SIGSEGV , and step from there. There are several techniques to achieve this, reverse debugging is one of them. Using replay debugging is another.

It's hard to offer more advice, because you didn't show what you are actually trying to do.

Answer 2

Are you sure you need to step through glibc code in fileops.c ?

If you want only to debug your own code you should finish current frame to go out of _IO_new_file_xsputn function after you have stepped into it and continue debugging your code.

Answer 3

That's how step works - it step s through the code.

What about a breakpoint? If you set one the debugger will stop there and let you step through the code manually.

For something like a segmentation fault or similar signals, which abort execution, you can run and backtrace when the program has stopped to gain information about the location execution has stopped at. Then set a breakpoint there and the program will stop at the offending instruction.