Question

I am trying to debug a program that needs to read EOF as an input.

However, when I hit Control-D to send EOF when the program is running in GDB, GDB traps the EOF and does not pass it to the application.

How can I cause gdb to send the EOF to the application?

Answer 1

However, when I hit Control-D to send EOF when the program is running in GDB, GDB traps the EOF and does not pass it to the application.

GDB does not do any such thing.

In a normal (all-stop) mode, either the application, or the GDB has control of the terminal, but not both.

If the application is reading the terminal input, then Control-D will cause it to read EOF, and GDB will not interfere with that.

If you are looking at the (gdb) prompt, then the application is not reading the input — it is stopped — and sending Control-D will indeed send EOF to GDB. Don’t do that.

Example:

gdb -q /bin/cat
Reading symbols from /bin/cat...done.

(gdb) run
Starting program: /bin/cat 
foof     # my input
foof     # cat output
         # Control-D
[Inferior 1 (process 12782) exited normally]  # cat received EOF and exited
(gdb) run
Starting program: /bin/cat 
foof     # my input
foof     # cat output
^C
Program received signal SIGINT, Interrupt.
0x00007ffff7b31ee0 in __read_nocancel () at ../sysdeps/unix/syscall-template.S:82
82  ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) quit   # I typed Control-D, GDB translated that into quit
A debugging session is active.

    Inferior 1 [process 12787] will be killed.

Quit anyway? (y or n) y

Update:

I am hitting Control-D when the application is reading (not at gdb prompt), and the application does not acknowledge that it received Control-D. When the application tries to read, it reads 0 bytes.

That’s exactly what is supposed to have happened (read returning 0 means that you’ve reached end of file). If you are expecting the application to read magical EOF symbol, your expectation is wrong — there is no such symbol.