I am running GDB 7.5 (Fedora 7.5.1-38.fc18) under emacs 24.2.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.6.4) with the default command META-x gdb ENTER ("gdb -i=mi")
It seems that GDB command lines that end with "\" just before the newline are mishandled. The debugger apparently ignores the entire line.
For example, after loading the target program, try starting it with the command line
(gdb) run FOO BAR \
and finish with an unquoted newline (ENTER). The response is
Undefined command: "BAZ". Try "help".
and the target program is NOT started.
This behavior is rather annoying since my target programs often have lots of arguments and are executed from Makefiles by multiline commands with backlash-quoted newlines, like
-source s1_bl1 \
-subject 001 \
-outPrefix out/split \
-framesPerRun 5400 \
-firstRun 001 \
-pulsesPerRun 4 \
-trigger TR -nElectrodes 20 \
-fSampling 600 \
With some older version of GBD I could simply copy-paste the command arguments above from the "*compilation*" buffer to the GDB buffer and hit ENTER. Now I have to manually remove the backslashes every time.
I've been talking to Jorge about this, and I am strongly inclined to believe that it is Emacs' (i.e., gdb-mi's) fault. Will see if I can find the culprit.
May be an emacs 24 bug of course. The "older version" I mentioned was used under an older emacs too, as "gdb --annotate=3" I believe.
A little more investigation on this... On Emacs, lisp/progmodes/gdb-mi.el:gdb-send, I notice that the string being sent for processing is wrong. When one types:
(gdb) run \
The function gets called twice, first with "run \\", and next with "BAZ QUX", leading to the "Undefined command" error. So yeah, it seems the way Emacs parses things (or comint-mode, which is the mode used by gdb-mi to interact with the user, in this case) is wrong.
Since I'm sleepy now, I'll leave the bug opened and take a better look at it tomorrow/during the weekend, just to make sure everything is covered.
I was right, this was an issue with Emacs. I have fixed it there, you can take a look at:
Closing this bug as INVALID, then. Thank you for the report!